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Preface 


The  purpose  of  this  research  effort  is  to  develop  a 
conceptual  design  of  a  Decision  Support  System  (DSS)  which 
will  support  United  States  Central  Command  (USCENTCOM)  in 
determining  the  appropriate  military  force  size  and  type  in 
support  of  Noncombatant  Evacuation  Operations  (NEO).  This 
design  will  serve  as  a  statement  of  USCENTCOM  NEO  planners’ 
requirements  for  a  total  DSS  to  be  developed.  The 
methodology  used  in  this  research,  the  adaptive  design 
process,  is  especially  suited  to  deal  with  subjective, 
unstructured  problems  such  as  the  decision  process  involved 
in  force  structure  determination. 

In  performing  this  research  and  writing  this  thesis  I 
have  had  a  great  deal  of  help  and  encouragement  from 
several  people.  I  am  deeply  indebted  to  my  thesis  advisor, 
Lt  Col  John  R.  Valusek,  for  his  patience,  understanding, 
and  perseverance.  I  would  like  to  express  my  appreciation 
to  JCS-J8  for  the  financial  support  which  allowed  this  to 
happen.  I  also  wish  to  thank  CDR  Freeman,  LTC  Milano,  and 
MAJ  Combs  at  USCENTCOM  for  their  assistance  and  cooperation 
during  the  early  stages  of  the  thesis  effort.  A  word  of 
thanks  is  also  owed  to  MAJ  Chuck  Fletcher  for  his  untiring 
patience  in  tutoring  me  on  the  Apple  II.  Finally,  I  wish 
to  thank  my  fiance  Mary  Jane  for  her  encouragement  and 
patience  during  these  past  few  months. 


Stephen  R.  Kostek 
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Abstract 

I 

Perhaps  the  most  sensitive  and  most  likely  to  occur 
crisis  operation  within  any  of  the  geographically  oriented 
unified  commands  is  the  conduct  of  Noncombatant  Evacuation 
Operations  (NEO).  NEO  is  a  system  which  has  been  developed 
in  order  to  evacuate  all  U.S.  civilians  and  military 
dependents  from  a  given  area  in  the  event  of  an  emergency 
situation  which  poses  a  threat  to  their  safety.  The 
purpose  of  this  research  effort  is  to  develop  a  conceptual 
design  of  a  Decision  Support  System  (DSS)  which  will 
support  one  of  the  unified  commands,  United  States  Central 
Command  (USCENTCOM),  in  determining  the  appropriate 
military  force  size  and  type  to  be  used  to  support  the  NEO. 
The  major  problem  with  determining  the  command  and  control 
planning  requirements  is  that  the  command  and  control 
required  for  the  conduct  of  a  NEO  presents  a  very 
unstructured  problem  area.  The  most  significant  factors 
which  impact  and  cause  NEO  to  be  an  unstructured  problem 
are  the  time  constraints  involved  and  the  need  for 
intuitive  (i.e.  subjective)  input  versus  objective  input  in 
the  military  force  size  determination.  This  paper  expands 
on  the  methodology  used  to  capture  the  subjective 
judgements  and  planning  factors  taken  into  consideration  by 
the  USCENTCOM  NEO  planners  and  at  the  same  time  provide  the 

vi 


DSS  builder  an  objective  framework  on  which  to  build  a 
supporting  system.  *  This  methodology,  often  referred  to  as 
rapid  prototyping  or  the  adaptive  design  process,  has  been 
used  to  develop  the  concept  DSS.  Requiring  a  high  level  of 
user  participation  and  involvement,  the  experimental 
adaptive  design  approach  used  in  this  research  combines 
such  techniques  as  concept  mapping,  storyboarding,  and 
feature  charts  to  determine  DSS  requirements  and  capture 
the  decision  process  used  by  the  NEO  planners.  Using  these 
techniques,  a  problem  space  is  defined  and  bounded.  From 
this  problem  space,  a  key  subproblem  or  "kernel"  iB 
identified  which  forms  the  basis  of  the  DSS.  This  thesis 
discusses  these  techniques  and  illustrates  how  they  were 
incorporated  and  expanded  upon  in  the  conceptual 
development  of  the  specific  NEO  Decision  Support  System. 
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A  USER’S  DESIGN  OF  A 
DECISION  SUPPORT  SYSTEM  FOR 
NONCOMBATANT  EVACUATION  OPERATIONS 
FOR  UNITED  STATES  CENTRAL  COMMAND 

I  BACKGROUND 

Background 

United  States  Central  Command  (USCENTCOM).  USCENTCOM 
is  located  at  MacDill  Air  Force  Base  in  Tampa,  Florida,  and 
is  a  unified  command  subordinate  to  the  Joint  Chiefs  of 
Staff  (JCS).  Originally  designated  as  the  Rapid  Deployment 
Joint  Task  Force  (RDJTF)  in  1979,  USCENTCOM  is  a 
geographically  oriented  unified  command  responsible  for  the 
Southwest  Asia  theater  of  operations.  USCENTCOM  has  the 
responsibility  to  observe  and  monitor  events  in  its  area  of 
responsibility  and  to  plan  and  conduct  military  operations 
on  order  from  JCS. 

Perhaps  the  most  sensitive  and  most  likely  to  occur 
crisis  operation  within  USCENTCOM’s  Area  of  Responsibility 
(AOR)  is  the  conduct  of  Noncombatant  Evacuation  Operations 
(NEO).  NEO  is  a  system  which  has  been  developed  in  order 
to  evacuate  all  U.S.  civilians  and  military  dependents  from 
a  given  area  in  the  event  of  an  emergency  situation  which 
poses  a  threat  to  their  safety.  Such  an  emergency 
situation  requiring  military  intervention  may  develop  with 
very  little  warning. 


Because  of  its  political  sensitivity,  evacuation  from 
any  given  country  is  usually  taken  as  a  last  resort.  Also, 
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the  decision  to  evacuate  is  a  judgement  call  made  by  the 
U.S.  ambassador  in  that  country  and  approved  by  the  U.S. 
State  Department  (Freeman,  1987).  This  decision  is  usually 
made  when  the  situation  has  deteriorated  to  the  point  where 
continued  presence  in  the  host  country  is  dangerous  to  U.S. 
citizens,  but  the  host  country  can  still  guarantee  some 
degree  of  protection  and  ensure  a  safe  evacuation. 

However,  there  is  a  very  fine  line  which  can  be  crossed 
when  the  situation  deteriorates  faster  than  the  decision 
can  be  made  to  evacuate  with  host  country  assistance.  When 
the  host  country  can  no  longer  guarantee  the  safety  of  U.S. 
citizens  and  dependents,  the  ambassador  identifies  the  need 
for  U.S.  military  intervention  through  the  State  Department 
to  provide  the  necessary  security  to  ensure  a  safe 
evacuation  of  all  U.S.  noncombatants.  Obviously,  the 
planned  introduction  of  U.S.  combat  forces  in  a  foreign 
country  is  a  very  significant  and  politically  sensitive 
issue  (Freeman,  1987). 

Throughout  the  potentially  brief  decision  process 
outlined  above,  USCENTCOM  personnel  would  have  been 
monitoring  the  situation  and  performing  their  own  crisis 
assessment.  Additionally,  USCENTCOM  planners  would  have 
been  developing  alternative  courses  of  action  to  support 
NEO  in  the  event  of  a  request  for  U.S.  military 
intervention  and  a  subsequent  JCS  warning  order.  The  most 
significant  problem  which  faces  USCENTCOM  planners  in  the 
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development  of  courses  of  action  is  the  limited  amount  of 
time  available.  By  its  very  nature,  planning  in  a  crisis 
situation  is  very  time-sensitive  and  may  be  subject  to 
error  because  of  ( 1 )  reduced  access  to  deployment  data 
(operations  security  implications)  and  (2)  not  having  the 
time  to  develop  or  consider  all  possible  options. 
Additionally,  many  of  the  staff  officers  assigned  to  the 
joint  commands  have  little  or  no  experience  in  the  joint 
contingency  planning  arena.  These  problem  areas  have  the 
potential  to  produce  plans  which  do  not  reflect  the  true 
military  situation  and  consequently  result  in  failure. 
Although  USCENTCOM  planners  will  have  been  assessing  the 
situation  and  developing  NEO  courses  of  action  before  the 
JCS  warning  order  is  received,  the  largest  problem 
continues  to  be  the  limited  amount  of  time  available. 

Based  on  past  experience,  "USCENTCOM  planners  ideally  need 
one  to  two  weeks  to  develop  and  evaluate  NEO  courses  of 
action”  (Freeman,  1987).  This  is  not  acceptable, 
especially  if  the  situation  in  a  host  country  deteriorates 
more  rapidly  than  estimated  and  the  JCS  warning  order 
requires  USCENTCOM  to  take  military  action  within  24  to  48 
hours . 

Besides  the  limited  amount  of  time  available,  another 
significant  problem  facing  USCENTCOM  NEO  planners  is  the 
determination  of  the  size  and  type  of  the  military  force 
needed  to  provide  and  ensure  the  security  of  all  U.S. 


*»  *» 


& 

ttt 


noncombatants  in  the  evacuation  process.  Presently,  the 
determination  of  the  size  and  type  of  the  military  force 
needed  is  the  result  of  a  multitude  of  factors  and  remains 


a  largely  unstructured  decision  process.  Some  of  the 
factors  which  have  an  impact  are: 

1)  the  host  country  environment  (i.e.  semipermi ss i ve , 
nonpermissive/ho8tile )  ; 

2)  threat  disposition  and  composition; 

3)  number  of  U.S.  noncombatants;  and 

4)  location  and  distances  between  locations  of 
noncombatants . 

Presently,  all  of  these  factors  form  the  basis  of 
determining  the  military  force  size  and  type,  but  the  final 
determination  is  still  a  very  subjective  call  on  the  part 
of  the  decision  maker.  The  decision  maker  in  a  Southwest 
Asia  NEO  scenario  is  the  Commander-In-Chief,  USCENTCOM 
(CINCCENT).  Due  to  the  distances  involved  between  the 
United  States  and  USCENTCOM’ s  AOR ,  the  ability  to  project 
military  power  is  significantly  degraded.  Forces  are  not 
readily  available  in  the  AOR  and  consequently  must  be 
transported  by  air  and  sustained  over  an  8,000-mile  leg. 
Additionally,  because  of  the  reduced  amount  of  planning 
time  available  in  a  crisis  situation  requiring  NEO  and  the 
factors  outlined  above,  many  constraints  impact  the  force 
type  and  size  determination  process.  Essentially,  the 
combination  of  these  factors  results  in  a  very  succinct 
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"economy  of  force"  measure  where  the  decision  maker  (i.e. 
CINCCENT)  must  determine  the  minimum  size  force  needed  to 
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perform  the  mission  of  providing  the  necessary  security  to 
ensure  the  safe  evacuation  of  all  U.S.  noncombatants. 

There  are  17  countries  in  USCENTCOM’s  AOR .  Most  of 
the  countries  have  coastlines;  and  consequently,  evacuation 
can  be  conducted  using  the  ships  of  U.S.  Naval  Forces  in 
the  area  thereby  reducing  airlift  requirements,  assuming 
time  is  available.  However,  the  most  difficult  NEO 
situation  exists  in  a  host  country  where  the  U.S. 
noncombatants  are  isolated  from  the  sea;  and  therefore, 
both  insertion  of  military  forces  and  evacuation  of 
noncombatants  is  required  by  air.  The  airlift  factor 
critically  impacts  on  the  size  of  the  plausible  military 
force.  The  airlift  acts  as  a  constraint  to  limit  the 
needed  forces. 

Once  the  size  and  type  of  the  military  force  has  been 
determined,  various  courses  of  action  are  developed  to 
support  the  NEO.  An  important  step  which  must  be  performed 
after  courses  of  action  are  developed  is  an  analysis  of 
those  courses  of  action.  This  analysis  is  done  with 
respect  to  each  course  of  action  so  that  the  course  of 
action  which  offers  the  highest  probability  of  success  can 
be  determined.  In  this  situation,  success  is  defined  as 
the  safe  evacuation  of  all  U.S.  noncombatants  using  the 
smallest  possible  force.  Because  of  the  crisis  situation 
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and  the  limited  amount  of  time  available,  a  detailed  course 
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of  action  assessment  is  often  not  conducted.  Consequently, 
the  NEO  could  result  in  failure. 

USCENTCOM  NEO  planners  are  aware  of  the  problem  areas 
and  the  constraining  factors,  and  are  seeking  methods  to 
improve  the  development  and  assessment  of  courses  of  action 
while  reducing  the  time  required  to  do  so.  However,  in 
spite  of  the  fact  that  NEO  is  a  very  sensitive  issue  and 
one  of  the  most  likely  USCENTCOM  missions  given  its  AOR,  it 
remains  a  lower  priority  area  when  compared  with  the 
deliberate  planning  efforts  required  for  USCENTCOM’s  other 
missions . 
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Research  Problem 

The  time  constraint  which  impacts  on  the  available 
planning  time  to  develop  NEO  courses  of  action  is  a  problem 
area  at  USCENTCOM  because  of  the  peculiar  requirements  of  a 
NEO  environment  and  the  number  of  factors  involved  in 
determining  the  appropriate  military  force  size  and  type. 

It  may  be  beneficial  to  investigate  computer  aids  for  the 
decision  process  of  determining  the  military  force  needed 
to  ensure  the  safe  evacuation  of  U.S.  noncombatants. 

Research  Objectives 

1)  The  purpose  of  this  research  effort  is  to  develop 
a  conceptual  design  of  a  Decision  Support  System  (DSS) 
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which  will  support  USCENTCOM  in  determining  the  appropriate 


military  force  size  and  type.  This  design  will  serve  as  a 
statement  of  USCENTCOM  NEO  planner’s  requirements  for  a 
total  DSS  to  be  developed. 

2)  A  second  objective  is  to  investigate  adaptive 
design  as  a  process  to  be  used  to  support  USCENTCOM  NEO 
planners  in  the  design  of  the  DSS. 

Scope  and  Limitations 

The  process  of  determining  the  appropriate  military 
force  size  and  type  as  part  of  a  total  DSS  will  be  scoped 
to  one  country  (i.e.  Sudan)  within  USCENTCOM’s  area  of 
responsibility.  The  decision  process  for  military  force 
size  determination  should  remain  relatively  unchanged  from 
one  country  to  another. 

The  scope  of  this  research  will  be  to  develop  a 
conceptual  design  of  a  DSS  to  be  used  by  USCENTCOM  in 
defining  their  requirements  for  a  NEO  DSS. 

The  remainder  of  this  thesis  is  divided  as  follows. 
Chapter  Two  presents  a  limited  literature  review  of  the 
methodology  used  in  this  research  effort.  Chapter  Three 
addresses  how  the  methodology  was  used  in  the  application 
of  the  adaptive  design  approach  to  a  specific  NEO  Decision 
Support  System.  It  also  serves  as  a  statement  of 
requirements  for  USCENTCOM.  Chapter  Four  provides  the 
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conclusions  and  recommendations  for  resolving  the  research 
problem,  the  value  of  the  adaptive  design  approach,  and  the 
direction  for  further  research  and  future  implementation. 
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II  METHODOLOGY 


Introduction 

As  described  in  Chapter  One,  the  purpose  of  this 
research  effort  is  to  determine  USCENTCOM  command  and 
control  planning  requirements  for  conducting  Noncombatant 
Evacuation  Operations  (NEO).  More  specifically,  the 
objective  is  to  develop  a  conceptual  design  of  a  Decision 
Support  System  (DSS)  which  will  support  USCENTCOM  in 
determining  the  appropriate  military  force  size  and  type  to 
be  used  to  support  NEO.  The  major  problem  with  determining 
the  command  and  control  planning  requirements  is  that  the 
command  and  control  required  for  the  conduct  of  a  NEO 
presents  a  very  unstructured  problem  area.  The  most 
significant  factors  which  result  in  NEO  being  an 
unstructured  problem  are  the  time  constraints  and  the  need 
for  intuitive  (i.e.  subjective)  input  versus  objective  in 
the  military  force  size  determination.  What  is  required  is 
a  methodology  which  can  capture  the  subjective  judgements 


of  the  USCENTCOM  NEO  planners  and  at  the  same  time  provide 
the  DSS  designer/builder  a  framework  on  which  to  build  a 
supporting  system. 


This  chapter  begins  by  discussing  the  present  crisis 
action  system  and  some  general  inadequacies.  Chapter  Two 
then  discusses  decision  support  systems  in  general,  the 


adaptive  design  methodology  and  the  three  experimental 
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techniques  used  to  support  this  methodology:  concept 
mapping,  storyboarding,  and  feature  charting. 
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Crisis  Action  System 

After  a  series  of  crises  in  the  early  1970's,  the 
National  Command  Authority  (NCA)  became  concerned  that  the 
military  organization  for  responding  to  crisis  situations 
was  ineffective  and  that  the  reporting  structure  was  not 
providing  adequate  and  timely  information  to  support  the 
decision  making  process.  Consequently,  a  Bystem  for  time- 
sensitive  planning  was  developed  called  the  Crisis  Action 
System  (CAS)  (AFSC  Pub  1,  1986:  7-4). 

Due  to  the  time  constraints,  political  sensitivity,  as 
well  as  the  immediate  danger  to  the  lives  of  U.S. 
noncombatants,  NEO  is  considered  as  a  response  to  some 
crisis  and  falls  under  the  auspices  of  the  Crisis  Action 
System . 

The  Crisis  Action  System  is  composed  of  six  distinct 
phases.  In  really  time-sensitive  crises,  these  phases  may 
be  combined  or  eliminated.  These  six  phases  are: 


1) 

Situation 

development , 

2) 

Crisis  assessment, 

3) 

Course  of 

action  development, 

4) 

Course  of 

action  selection, 

5) 

Execution 

planning,  and 

6) 

Execution 

(AFSC  Pub  1,  1986: 
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For  the  purpose  of  this  research  effort  and  the  objective 
of  this  thesis,  only  the  course  of  action  (CO A)  development 
phase  will  be  discussed. 

In  the  COA  development  phase,  USCINCCENT  develops  and 
recommends  one  or  more  COAs  to  the  Joint  Chiefs  of  Staff 
(JCS)  in  a  commander’s  estimate.  The  development  of  these 
COAs  which  include  force  selection,  alerting,  and 
preparation  is  usually  in  response  to  a  JCS  WARNING  ORDER 
( AFSC  Pub  1,  1986:  7-10).  In  a  NEO  situation,  USCENTCOM 
planners  have  access  to  existing  contingency  plans  which 
must  be  expanded  upon  in  order  to  execute  the  NEO.  The 
most  critical  element  facing  the  planners  is  time. 

Presently,  when  a  crisis  situation  erupts  at  USCENTCOM 
an  ad  hoc  planning  group  is  created  in  response  to  that 
specific  crisis  (Freeman,  1987).  Usually  the  members  of 
this  group  have  the  brightest  minds,  but  unfortunately  have 
not  worked  with  each  other  on  a  continual  basis  and 
consequently  strengths  and  weaknesses  of  individual  players 
are  unknown.  This  is  not  a  unique  situation;  most 
commands  follow  this  procedure  in  creating  ad  hoc  groups  to 
address  crisis  situations.  This  may  not  be  the  best  use  of 
personnel  resources. 

However,  even  using  the  present  CAS  in  place,  the 
development  of  COAs  by  the  planning  group  is  essentially  a 
"stubby  pencil"  drill.  This  may  not  be  a  good  approach 
given  the  availability  of  computer  resources  and  large  data 
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bases.  The  "stubby  pencil"  drill  needs  automation  support 
to  make  maximum  use  of  the  resources  and  limited  time 
available.  Therefore,  a  system  that  is  flexible,  adaptable 
and  that  supports  the  force  size  determination  process 
seems  to  be  more  appropriate. 

Decision  Support  Systems 

An  approach  or  methodology  to  developing  a  NEO  force 
size  decision  aid  is  the  adaptive  design  or  rapid 
prototyping  process  used  in  building  decision  support 
systems.  The  field  of  decision  support  systems  (DSS)  is 
still  young  and  appears  to  be  growing  with  time  and  a  wider 
range  of  acceptance.  Consequently,  there  is  not  one 
standard  definition  for  a  DSS.  Valusek  defines  a  DSS  as  "a 
system,  manual  or  automated,  that  aids  a  decision  maker  in 
the  cognitive  processes  of  judgement  and  choice"  (Valusek, 
1987).  According  to  Keen  and  Scott-Morton ,  "a  DSS  implies 
the  use  of  computer  hardware  and  software  to: 

1)  Assist  managers  in  their  decision  process  in 
semi -structured  tasks. 

2)  Support,  rather  than  replace,  managerial 
judgement . 

3)  Improve  the  effectiveness  of  decisionmaking 
rather  than  its  efficiency"  (Keen  and  Scott 
-Morton,  1978:  1). 

Watson  and  Hill  define  a  DSS  as  "an  interactive  system 
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that  provides  the  user  with  easy  access  to  decision  models 
and  data  in  order  to  support  semistructured  and 
unstructured  decision-making  tasks"  (Watson  and  Hill,  1983 
82).  Alavi  and  Napier  define  a  DSS  as  "computer  based 
systems  designed  to  enhance  the  effectiveness  of  decision 
makers  in  performing  semi-structured  tasks.  With  such 
tasks,  the  decision  maker  is  uncertain  about  the  nature  of 
the  problem/opportunity,  the  alternative  solutions,  and/or 
the  criteria  or  value  for  making  a  choice.  Hence,  the 
primary  role  of  a  DSS  is  to  aid  the  judgement  processes  as 
the  decision  maker  contends  with  poorly  defined  problems" 
(Alavi  and  Napier,  1984:  21).  Hagwood  restricts  his 
definition  of  the  term  DSS  to  "computer  based  systems  for 
supporting  non-repeti t ive  unstructured  or  semistructured 
organizational  decisions"  (Hagwood,  1986:  3).  Sprague  and 
Carlson  prefer  to  define  a  DSS  in  terms  of  the 
characteristics  which  DSSs  should  possess: 

"1)  Decision  focused,  aimed  at  top  managers  and 
executive  decision  makers. 

2)  Emphasis  on  flexibility,  adaptability  and 
quick  response. 

3)  User  initiated  and  controlled. 

4)  Support  for  the  personal  deciBion-making 
styles  of  individual  managers"  (Sprague  and 
Carlson ,  1982:  7  )  . 

Some  other  observed  DSS  characteristics,  according  to 


Sprague,  which  have  evolved  from  the  work  of  Alter,  Keen, 
and  others  include: 


”1)  They  tend  to  be  aimed  at  the  less  well 

structured,  underspecified  problems  that 
upper-level  managers  typically  face. 

2)  They  attempt  to  combine  the  use  of  models  or 
analytic  techniques  with  traditional  data 
access  and  retrieval  functions. 

3)  They  specifically  focus  on  features  that  make 
them  easy  to  use  by  noncomputer  people  in  an 
interactive  mode. 

4)  They  emphasize  flexibility  and  adaptability 
to  accomodate  changes  in  the  environment  and 
decision-making  approach  of  the  user" 

(Sprague  and  CarlBon,  1982:  6). 

The  terms  unstructured  and  semistructured  problems  are 
terms  which  are  mentioned  in  several  of  the  DSS  definitions 
discussed  previously,  but  what  do  they  mean.  Burleson 
defines  unstructured  problems  as  those  problems  which  have 
time  constraints,  a  need  for  intuitive  inputs,  require  a 
large  search  time,  or  there  is  some  uncertainty  about  some 
of  the  decision  parameters  (Burleson  and  others,  1986:  57). 
Meador  and  Rosenfeld  define  a  semistructured  decision¬ 
making  environment  as  one  that  is  not  well  enough 
understood  to  permit  a  complete  analytical  description 
(Meador  and  Rosenfeld,  1986:  160). 
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In  order  to  develop  an  effective  DSS,  a  different, 
more  flexible  approach  must  be  used  versus  the  traditional 
approach  to  system  development.  Alavi  and  Napier  state 
that  "the  very  nature  of  a  DSS  requires  a  design  method 
different  from  the  traditional  life  cycle  approach  for  the 
development  of  transaction  processing  systems"  (Alavi  and 
Napier,  1984:  21).  One  of  the  reasons  for  a  different  and 
more  flexible  approach  may  be  because  of  the  psychological 
limitations  of  the  user.  Users  are  often  not  able  to 
define  the  problem  space  or  state  their  requirements.  They 
may  have  an  idea  of  what  they  need  but  are  simply  unable  to 
verbalize  it.  However,  when  the  user  sees  something 
definitive  on  paper,  it  is  much  easier  for  him  to  request 
changes  because  he  is  working  from  some  established  format. 
Essentially,  the  user  is  stating  that  "I  don't  know  what  I 
want,  but  I’ll  know  when  I  see  it"  (Valusek,  1987). 

Sprague  and  Carlson  explain  their  reasons  why  DSS  requires 
a  different  design  technique  from  the  traditional  approach 
by  stating,  "Because  there  is  no  comprehensive  theory  of 
decision  making,  and  because  of  the  rapidity  of  change  in 
the  conditions  that  decision  makers  face,  the  traditional 
approaches  for  analysis  and  design  have  proven  inadequate. 
Designers  literally  cannot  get  to  first  base  because  no 
one,  least  of  all  the  decision  maker  or  user,  can  define  in 


advance  what  the  functional  requirements  of  the  system 
should  be”  (Sprague  and  Carlson,  1982:  15).  In  order  to 
have  a  better  grasp  of  the  differences  between  adaptive 
design  and  the  traditional  design  process  addressed  above, 
it  may  be  useful  to  provide  a  short  explanation  of  the 
traditional  approach. 

The  traditional  systems  development  approach  takes  the 
form  of  five  distinct  steps.  These  steps  are: 

”1)  Determine  the  system  requirements; 

2)  Design  the  system; 

3)  Develop  the  system; 

4)  Implement  the  system;  and 

5)  Evaluate  the  system"  (Valusek,  1987). 

A  problem  area  with  this  approach  is  that  the  DSS 
builder/designer  must  "freeze"  the  requirements  at  some 
point  in  order  to  start  the  development  process. 
Consequently,  once  requirements  are  stated,  any  change  in 
requirements  will  not  affect  the  design  process.  This 
freezing  of  the  requirements  snowballs  throughout  the 
entire  traditional  approach  in  the  system  design, 
development,  and  implementation  steps.  Only  after  the 
evaluation  has  been  conducted  can  new  requirements  be 
accepted  and  then  the  whole  process  is  started  over  again. 
One  iteration  of  this  approach  can  and  usually  does  take  up 
to  several  years  (Valusek,  1987).  User  generated 
requirements  cannot  be  incorporated  rapidly  into  the 
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traditional  system  development  process.  Consequently,  the 

system  is  very  inflexible  and  wastes  both  time  and  money. 

Another  problem  with  the  traditional  approach  is  that  there 

is  limited  contact  between  the  user  and  designer/builder 

until  the  evaluation  step.  This  step  is  just  too  late  in 

the  cycle  to  accommodate  any  rapidly  changing  situations 

which  may  impact  on  the  user  during  the  ongoing  DSS  design 

step.  If  the  DSS  is  going  to  work,  it  needs  to  be  user 

oriented.  Rouse  and  Rouse  state  that  "another  potential 

explanation  for  decision  aids  not  being  accepted  is  that 

user  participation  in  design  has  not  been  given  the 

necessary  primacy"  (Rouse  and  Rouse,  1983:  1). 

The  adaptive  design  approach  follows  the  same  format 

as  the  traditional  design  approach  except  it  reduces  the 

time  required  to  complete  one  iteration  of  the  development 

cycle  from  what  may  be  several  years  to  several  weeks. 

Sprague  and  Carlson  state  that: 

DSS  need  to  be  built  with  short,  rapid  feedback  from 
users  to  ensure  that  development  is  proceeding 
correctly.  They  must  be  developed  to  permit  change 
quickly  and  easily.  The  result  is  that  the  most 
important  four  steps  in  the  typical  systems 
development  process  (analysis,  design,  construction, 
implementation)  are  combined  into  a  single  Btep  which 
is  iteratively  repeated.  The  essence  of  this  approach 
is  that  the  manager  and  builder  agree  on  a  small  but 
significant  subproblem,  then  design  and  develop  an 
initial  system  to  support  the  decision  making  that  it 
requires  (Sprague  and  Carlson,  1982:  15). 

Strong  support  for  the  adaptive  design  approach  is 

expressed  by  Keen  when  he  states  the  following  reasons: 

”1)  The  designer  or  user  cannot  provide 
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functional  specifications  or  is  unwilling  to 
do  so . 

2)  Users  do  not  know  what  they  want  and  the 
designers  do  not  understand  what  they  need  or 
can  accept. 

3)  Users’  concepts  of  the  task  or  decision 
situation  will  be  shaped  by  the  DSS . 

4)  Intended  users  of  the  system  have  sufficient 
autonomy  to  handle  the  task  in  a  variety  of 
ways"  (Keen,  1980:  15). 

After  illustrating  the  need  for  the  adaptive  design 
process  in  building  a  DSS,  the  process  needs  to  be 
addressed  itself.  There  are  five  principal  steps  in 
adaptive  design.  Tnese  steps  are: 

1)  Select  the  right  problem; 

2)  Identify  key  decisions  or  kernels  in  the 
problem ; 

3)  Perform  a  requirements  analysis  of  the 
kernel ; 

4)  Iterate  until  an  acceptable  design  is  made; 

5)  Implement  the  system  (Valusek,  1987). 

It  must  be  kept  in  mind  that  along  with  these  steps  the 
user  and  builder  are  always  meeting  with  each  other  and 
constantly  evaluating  the  system's  development  to  date. 

In  an  experiment  in  applying  the  adaptive  design 
approach  to  DSS  development,  Alavi  and  Napier  offered  some 
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important  conclusions.  These  were: 

"1)  The  adaptive  design  approach  requires  a  high 
level  of  user  participation  and  involvement. 

2)  Rapid  progress  in  defining  the  user 
requirements  and  developing  DSS  capabilities 
during  the  early  stages  of  the  development 
process  establishes  the  credibility  of  the 
DSS  builder  and  leads  to  user  cooperation. 

3)  A  DSS  generator  is  a  critical  factor  in  the 
application  of  the  approach. 

4)  The  adaptive  design  approach  seems  to  reduce 
the  requirement  for  formal  user  training. 

5)  The  perceived  value  of  the  DSS  during  the 
early  stages  of  the  adaptive  design  process 
seems  to  be  the  necessary  incentive  for  its 
adoption  by  the  user"  (Alavi  and  Napier, 

1984:  21). 

Techniques 

In  order  to  determine  what  the  problem  space  really 
is,  and  to  identify  the  important  subproblem  which  will 
serve  as  the  nucleus  of  the  evolving  system  as  well  as 
portraying  the  decision  process,  various  techniques  are 
being  experimented  with.  These  techniques  include  concept 
mapping,  storyboarding  and  feature  charting.  Each  of  these 
techniques  will  be  covered  in  the  remainder  of  this 
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chapter . 


Concept  Mapping 

A  concept  map  provides  a  quick  and  general  bounding  of 
the  problem  space.  In  its  most  simple  case,  a  concept  map 
"is  two  or  more  concepts  that  are  linked  to  each  other 
depicting  a  meaningful  relationship"  (McFarren,  1987:  45). 

D.  Bob  Gowin  developed  the  use  of  concept  maps  as 
teaching  tools  while  at  Cornell  University.  He  explains 
that  "concept  maps  are  intended  to  represent  meaningful 
relationships  between  concepts  in  the  form  of  propositions. 
Propositions  are  two  or  more  concept  labels  linked  by  words 
in  a  semantic  unit"  (Gowin,  1984:  15).  A  simple  example  of 
a  concept  map  is  illustrated  in  Figure  1  below. 
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Figure  1.  Simple  Concept  Map 

The  example  given  above  illustrates  the  linkage  of  the  two 
propositions  in  boxes  linked  by  a  word. 

McFarren  expanded  upon  the  use  of  concept  mapping  in 
an  effort  to  determine  the  problem  space  and  consequently 


the  identification  of  information  requirements.  McFarren 
states  that  "Concept  mapping  is  designed  to  meet  the 
requirements  for  capturing  the  problem  space.  By 
identifying  the  key  factors  and  ideas  of  a  problem  space 
and  representing  their  relationships  to  each  other,  the 
problem  will  be  identified  and  described  by  a  map  of  the 
concepts"  (McFarren,  1987:  40).  An  example  of  a  more 
detailed  concept  map  is  illustrated  in  Figure  2  on  the 
following  page. 

One  of  the  most  important  steps  in  the  DSS  process  is 
the  concept  mapping  interview  conducted  between  the  user 
and  the  DSS  designer/builder.  "The  interview  is  a  face-to- 
face  meeting  with  the  user.  Its  goal  is  to  capture  the 
user's  understanding  of  the  problem  and  his/her  key 
decision  elements.  The  interview  is  the  most  significant 
part  of  the  entire  DSS  design  process  because  the 
information  and  perceptions  gained  by  the  designer  will  be 
reflected  in  the  final  product"  (McFarren,  1987:  74). 
Concept  mapping  allows  the  user/decisionmaker  to  better 
understand  the  problem  through  the  identification  of  key 
points  or  kernels  and  in  the  bounding  of  the  problem. 
McFarren  states  that  "the  kernel  is  a  key  decision  element 
within  the  decision  process.  It  provides  a  starting  point 
for  design  of  the  DSS"  (McFarren,  1987:  42). 

Once  a  concept  map  of  the  problem  space  has  been 
drawn,  the  next  step  is  to  construct  the  storyboards  which 
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model  the  decision  process  which  is  bounded  by  the  concept 
map . 


Storyboarding 

Storyboarding,  as  labeled  by  Andriole,  is  a  technique 
where  the  decision  process  is  portrayed  via  screen  displays 
during  the  requirements  analysis  process.  As  defined  by 
Andriole,  "A  storyboard  is  a  sequence  of  displays  that 
represents  the  functions  that  the  system  may  perform  when 
finally  implemented.  When  well  done,  it  communicates  to 
intended  users  system  functions  that  could  only  be 
described  piecemeal  in  static  paper  displays  or  words" 
(Andriole  and  others,  1987:  3).  In  this  case,  the  concept 
map  discussed  previously  forms  the  basis  of  the 
requirements  analysis. 

A  technique  that  should  be  used  when  developing 
storyboards  is  the  ROMC  approach  discussed  by  Sprague  and 
Carlson.  The  acronym  ROMC  is  based  on  four  separate 
functions:  Representations,  Operations,  Memory  Aids,  and 
Control  Mechanisms.  "The  capabilities  of  the  DSS  from  the 
user’s  point  of  view  derive  from  its  ability  to  provide 
representations  to  help  conceptualize  and  communicate  the 
problem  or  decision  situation,  operations  to  analyze  and 
manipulate  those  representations,  memory  aids  to  assist  the 
user  in  linking  the  representations  and  operations,  and 
control  mechanisms  to  handle  and  use  the  entire  system" 
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(Sprague  and  Carlson,  1982:  96).  Each  storyboard  needs  to 
satisfy  each  of  these  aspects.  Figure  3  provides  an 
example  of  what  one  screen  display  of  a  storyboard  may  look 


like. 

Once  the  design  of  the  storyboard  is  acceptable  to  the 
user,  the  last  step  is  to  show  the  connectivity  or 
sequencing  of  the  individual  screen  displays  of  the 
storyboard . 


Feature  Charting 

Feature  charting  was  proposed  by  Seagle  and  Belardo  as 
a  graphic  tool  for  analysis  and  communication.  It  was 
proposed  because  although  the  ROMC  approach  helped  classify 
the  components  of  the  decision  support  system,  it  did  not 
provide  the  analyst  with  the  means  of  conveying  the 
connectivity  of  representations  to  the  user  (Seagle  and 
Belardo,  1986:  11).  They  believed  that  "the  user  and  the 
designer  need  to  know  not  only  the  specific  controls, 
operations,  and  representations  available,  but  also  the 
various  paths  by  which  they  can  be  reached"  (Seagle  and 
Belardo,  1986:  13).  Essentially,  the  feature  chart  is  a 
flow  chart  depicting  the  interconnectivity  of  the 
storyboard  discussed  earlier.  Figure  4  on  the  page  26 
provides  an  example  of  a  feature  chart.  In  relating  the 
storyboard  to  the  feature  chart,  the  feature  chart  serves 
as  an  outline  of  the  entire  decision  process  in  the  DSS  and 
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Figure  3  -  Storyboard  Screen  Display 
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the  storyboard  frame  is  one  component  within  that  feature 
chart . 

The  techniques  of  concept  mapping,  storyboarding,  and 
feature  charting  are  all  analytical  techniques  designed  to 
support  the  adaptive  design  process.  These  innovative 
tools  provide  a  logical,  flexible  approach  to  frontend 
analysis.  The  very  use  of  these  tools  orients  the  design 
of  the  decision  support  system  on  the  user  which  is 
critical  to  the  adaptive  design  process. 

Chapter  Three  addresses  how  this  methodology  was  used 


in  the  application  of  the  adaptive  design  approach  to  a 
specific  NEO  Decision  Support  System. 


Ill  APPLICATION  OF  MBTHODOLOGY 


Introduction 

The  methodology  described  in  Chapter  Two  was  used  to 
define  the  problem  space  and  determine  the  command  and 
control  requirements  necessary  to  plan  a  successful 
Noncombatant  Evacuation  Operation  (NEO).  The  following 
narrative  provides  an  explanation  of  how  these  techniques 
were  used  to  narrow  the  problem  space  and  consequently 
satisfy  the  objectives  of  this  research  effort. 


Initial  Attempt 

First  Concept  Map  and  Storyboard 


The  first  step  taken  in  this  research  effort  was  to 
conduct  a  concept  mapping  interview  with  CDR  Dale  Freeman, 
an  experienced  naval  officer  working  as  the  J5  NEO  Plans 
Officer  for  USCENTCOM.  The  initial  question  that  was  asked 
of  CDR  Freeman  was  "What  type  of  information  is  required  by 
the  planners  at  USCENTCOM  to  plan  for  a  Noncombatant 
Evacuation  Operation?”.  The  concept  map  at  Figure  5,  on 
the  following  page,  provides  a  representation  of  CDR 
Freeman’s  response  to  that  question. 

Once  the  concept  map  was  completed,  the  next  step  in 
the  process  was  to  start  developing  a  storyboard,  composed 
of  various  prospective  screen  displays,  which  portray  the 
ideas  depicted  in  the  initial  concept  map.  Figure  6  shows 
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Figure  5  -  Initial  Concept  Map 
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the  initial  design  of  a  screen  display  within  the 
storyboard  called  "Evacuee  Data".  For  the  Bake  of 
simplicity,  the  storyboard  and  subsequent  screen  displays 
would  be  built  around  one  specific  country  within 
USCENTCOM’s  area  of  responsibility.  For  this  research 
effort,  the  country  of  Sudan  was  chosen  as  a  representative 
example . 


Selecting  a  Kernel 

After  the  first  storyboard  was  developed,  it  was 
necessary  to  identify  one  specific  idea  from  the  concept 
map  which  would  become  the  focal  point,  or  kernel,  upon 
which  to  expand.  The  reasons  for  doing  this  were  to:  1) 
use  the  adaptive  design  approach  in  starting  small  and 
producing  something  for  the  user,  2)  narrow  the  scope  of 
the  research  effort,  and  3)  identify  a  critical  planning 
factor  faced  by  NEO  planners  at  USCENTCOM.  After  careful 
examination  of  the  concept  map,  it  appeared  that  most  of 
the  ideas  depicted  were  information  factors  which 
contributed  to  or  impacted  on  one  central  planning  factor. 
This  factor,  or  kernel,  was  the  determination  of  the  size 
and  type  of  military  force  needed  to  conduct  the  NEO.  The 
other  information  factors  were  basically  statements  of 
fact,  whereas  the  kernel  required  some  subjective  or 


intuitive  input  common  to  most  complex  decision  making 


processes . 


Thus,  the  "force  size  determination"  kernel  was 
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determined  to  be  the  most  important  aspect  of  the  NEO 
planning  process  and  consequently  the  area  to  begin  design 
of  the  kernel  system. 


a 
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Factors  Impacting  on  the  Kernel 

Based  on  the  first  interview  and  resulting  concept 
map,  it  appeared  that  those  factors  which  impacted  on  the 
force  size  and  determination  process  were  a  function  of  the 
specific  Southwest  Asian  country,  the  specific  location  of 
the  noncombatants,  and  the  numbers  of  noncombatants  to  be 
evacuated.  In  addition  to  these  factors,  time  was  also 
identified  as  a  critical  constraint  on  the  NEO  planning 
process.  Keeping  these  factors  in  mind,  the  goal  of  this 
research  effort  was  to  design  a  Decision  Support  System 
which  would  have  access  to  the  necessary  data  in  order  to 
determine  the  NEO  military  force  size  and  type  needed  to 
insure  the  safe  evacuation  of  the  U.S.  noncombatants.  The 
objective  in  the  storyboard  than  changed  from  merely 
portraying  ideas  from  the  concept  map  to  a  sequential 
function  which  portrayed  the  thought  process  involved  in 
determining  the  necessary  force  structure  in  the  given  time 
constraints . 

Second  Attempt : Ref ining  the  Storyboard 

The  previous  storyboard  and  resulting  screen  displays 
were  a  "first  cut"  at  determining  and  consequently 
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displaying  those  factors  which  influenced  the  force  size 
determination  process.  The  question  which  had  to  be 
answered  was  "How  can  the  screen  displays  be  integrated  and 
combined  in  order  to  build  the  force  required  to  conduct 
the  NEO?".  These  "first  cut"  screen  displays  which 
provided  information  pertaining  to  the  threat,  noncombatant 
data,  road  networks,  airfield  and  port  data  became  the  data 
base  which  was  needed  to  build  the  security  force  required 
for  the  NEO.  In  other  words,  this  particular  data  base 
constituted  the  "intelligence  preparation"  base  needed 
before  the  force  could  be  built. 

Albeit  very  subjective,  the  "Blue  Force"  window  within 
each  screen  display  attempted  to  mirror  the  thought  process 
of  a  NEO  planner  in  building  a  security  force  by  accessing 
the  necessary  data  from  the  "intelligence  preparation" 
portions  of  the  storyboard.  Figure  7  depicts  a  screen 
display  pertaining  to  building  a  portion  of  the  security 
force.  In  this  case,  the  portion  of  the  force  needed  to 
insure  route  security  from  each  noncombatant  location  to 
the  evacuation  airfield.  This  screen  display  also 
illustrates  the  use  of  accessing  the  "intelligence 
preparation"  data  base  (i.e.  specific  route  threat  and  city 
roadnetwork  data)  in  order  for  the  planner  to  determine 
which  size  and  type  force  would  be  needed  along  each  route. 
It  should  also  be  noted  that  the  screen  display  design 
shifted  from  a  basic  display  to  a  pulldown  menu  display 
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format  which  allows  for  easier  access  to  information. 


Third  Attempt:  TDY  to  USCENTCOM 

Having  focused  the  problem  of  determining  command  and 
control  requirements  on  the  NEO  force  size  and  type 
determination  process,  and  keeping  in  mind  the  adaptive 
design  approach,  another  visit  was  made  to  J3  and  J5  NEO 
planners  at  USCENTCOM.  It  should  be  noted  at  this  point 
that  CDR  Freeman  had  departed  the  command  and  was  replaced 
by  LTC  O.J.  Milano  ( USMC )  as  the  J5  NEO  planner.  This 
change  in  planners  provided  an  excellent  opportunity  to 
test  the  flexibility  of  the  adaptive  design  approach  in 
designing  a  Decision  Support  System.  After  approximately 
eight  hours  of  interviews  with  two  NEO  planners,  a  new 
concept  map  was  developed  along  with  recommendations  to 
change  various  screen  displays  as  well  as  delete  and  add 
screen  displays  within  the  storyboard.  Perhaps  the  most 
important  part  of  this  visit  was  the  concept  map  which 
finally  evolved  during  the  interview  process.  The  concept 
map  was  restructured  and  provided  a  better  flow  of  those 
planning  factors  which  impacted  on  the  security  force  size 
and  type  determination  process.  This  concept  map, 
contained  in  Figure  8,  neatly  summarizes  those  planning 
factors.  Changes  from  the  initial  concept  map  are  enclosed 
in  a  dark  line.  The  principal  planning  factors  for 


determining  the  type  and  size  of  security  force  needed  are 


Figure  8  -  Final  NEO  Concept  Map 


time,  distance,  and  the  specific  threat  environment.  One 
of  the  more  significant  points  which  came  out  of  the 
interview  process  was  the  nature  of  the  impact  of  the 
threat.  Based  on  the  first  interview,  a  threat  environment 
was  determined  for  the  host  country  as  a  whole.  This  in 
fact  is  not  the  case  and  was  resolved  during  the  second 
interview.  The  specific  threat  environment  of  which  there 
are  three  (i.e.  semipermissive ,  nonpermissive ,  hostile)  are 
a  function  of  each  site  to  include  each  noncombatant 
location,  airfield,  and  evacuation  route.  This 
redefinition  of  the  impact  of  the  threat  environment  caused 
many  significant  changes  to  be  made  to  the  various  screen 
displays  within  the  storyboard,  along  with  an  expansion  of 
the  storyboard  itself. 


Refinement  of  the  Storyboard 

Based  on  the  interviews  at  USCENTCOM  and  the  refined 
concept  map,  the  screen  displays  contained  in  the  third 
version  of  the  storyboard  reflect  the  users’  requirements 
and  specific  needs.  This  storyboard,  a  NEO  DSS  for 
USCENTCOM,  is  illustrated  in  Appendix  A  of  this  document. 
Each  screen  display  within  the  storyboard  is  immediately 
preceded  by  an  explanation  of  what  is  taking  place  within 
that  particular  screen  display.  This  explanation  along 
with  each  screen  display  provide  a  continuity  flow  for  the 
reader  to  better  understand  the  process  which  is  taking 
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place  within  the  DSS  design. 

Feature  Chart 

The  feature  chart  can  also  be  found  on  the  last  page 
of  Appendix  A.  As  discussed  in  Chapter  two,  the  feature 
chart  depicts  the  connectivity  of  the  various  screen 
displays  within  the  storyboard.  Each  screen  display 
represents  a  step,  not  necessarily  sequential,  in  the 
thought  process  needed  to  determine  the  security  force  size 
and  type  for  the  NEO. 

Hookbook 

The  "hookbook"  concept  introduced  by  Lt  Col  ValuBek 
(Valusek,  1987)  was  valuable  in  terms  of  maintaining  a 
running  record  of  various  thoughts,  ideas,  or  suggestions. 
These  ideas  affected  the  direction  and  scope  of  the 
research  effort  and  provided  future  direction  in  terms  of 
recommendations  for  improvement  to  the  DSS.  For  the 
purposes  of  this  research  effort,  the  hookbook  was 
maintained  manually  using  3X5  cards.  Entries  on  each 
card  include  the  date,  the  specific  thought  or  idea,  and 
the  circumstances  under  which  this  thought  or  idea  was 
inspired.  At  the  end  of  the  research  effort,  all  the  cards 
were  consolidated  and  assigned  categories  (i.e.  DSS 
enhancement  or  adaptive  design).  Many  of  the  cards  were 
thrown  away  since  many  of  the  ideas  had  been  incorporated 
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during  the  research  effort  itself.  The  remaining  ideas 
consist  of  recommendations  for  DSS  enhancement  and 
recommendations  which  resulted  from  the  adaptive  design 
process.  These  "hookbook"  items  are  discussed  in  further 
detail  in  Appendix  C. 


Summary 

In  conclusion,  the  adaptive  design  process  as 
discussed  in  Chapter  Two  was  used  to  address  the  problem 
described  in  Chapter  One.  A  step-by-step  description  of 
the  application  of  the  adaptive  design  process  used  within 
this  research  effort  was  given  to  include  the  initial  and 
subsequent  development  of  concept  maps  and  the  storyboard. 
The  purpose  of  the  storyboard  is  to  show  in  pictorial  form 
the  ideas  reflected  in  the  concept  map  which  mirror  those 
factors  which  influence  the  planner’s  decision  process. 

Chapter  Four  summarizes  the  requirements  discovered  in 
the  course  of  this  research  as  well  as  the  application  of 
some  models  to  this  DSS.  Additionally,  comments  and 
recommendations  relative  to  DSS  design  and  particularly  the 
adaptive  design  approach  are  discussed.  Chapter  Four  also 
provides  particular  recommendations  to  enhance  and  improve 
the  NEO  DSS  design  developed  in  this  thesis. 
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IV  CONCLUSIONS  AND  RECOMMENDATIONS 


Introduction 

This  chapter  discusses  conclusions  and  recommendations 
for  the  two  major  areas  which  influenced  the  development  of 
this  thesis  effort.  First,  some  conclusions  are  provided 
regarding  the  design  of  the  Noncombatant  Evacuation 
Operation  (NEO)  Decision  Support  System  (DSS). 

Additionally,  some  recommendations  are  made  regarding  the 
integration  of  certain  models  which  can  support  the  NEO 
plan.  Second,  some  conclusions  are  drawn  relating  to  the 
use  of  the  adaptive  design  process  in  the  DSS  design. 
Finally,  some  recommendations  are  made  for  USCENTCOM 
relative  to  the  NEO  DSS  and  the  adaptive  design 
methodology.  Additional  recommendations  for  DSS 
enhancement  are  contained  in  Appendix  C,  Hookbook . 

NEO  Decision  Support  System  (DSS) 

Why  the  DSS  approach?  The  NEO  planning  process,  and 
more  specifically,  the  determination  of  the  military 
security  force  size  and  type  is  a  very  complex  decision 
process.  Referred  to  as  "fuzzy",  the  decision  of  what  size 
and  type  security  force  is  very  subjective  on  the  part  of 
the  NEO  planner  and  decision  maker.  It  is  dependent  on  a 
wide  range  of  factors,  some  of  which  are:  time,  distance, 
and  the  threat.  In  this  regard,  the  problem  of  determining 


the  military  force  size  and  type  is  relatively  unstructured 


which  is  common  to  many  decision  processes  in  the  command 
and  control  arena.  Additionally,  one  of  the  critical 
dimensions  faced  by  the  NEO  planner  is  the  amount  of  time 
available  to  develop  a  feasible  set  of  alternatives  and 
consequently  generate  a  NEO  plan.  Dictated  by  the  threat 
environment  facing  the  noncombatants,  the  time  available 
for  planning  may  be  as  little  as  24  to  48  hours.  Faced 
with  a  tremendous  amount  of  information  requirements,  the 
limited  time  available  and  the  unstructured  subjectivity  of 
the  decision  processes  involved,  it  was  evident  that  the 
NEO  planners  at  USCENTCOM  needed  an  elaborate  decision  aid. 
The  approach  which  appeared  to  satisfy  the  above 
constraints  was  the  design  and  ultimate  development  of  a 
Decision  Support  System. 

NEO  DSS  Development 

The  first  cut  at  the  NEO  DSS  design  is  complete  from 
the  designer’s  perspective,  but  should  be  made  available  to 
the  user  (i.e.  USCENTCOM  J 5 )  for  review  and  further 
comments.  This  review  needs  to  be  done  before  developing 
the  DSS  itself,  the  supporting  relational  data  base,  and 
the  determination  of  the  communication  links  required.  The 
DSS  design  as  incorporated  in  this  thesis  in  the  form  of  a 
storyboard  serves  two  purposes.  First,  the  storyboard 
screen  displays  with  accompanying  explanations  serves  as 


documentation  for  both  the  user  and  the  DSS  builder.  The 
user’s  embedded  training  is  contained  within  the 
storyboard,  and  consequently  there  is  no  need  for  a 
separate  user’s  manual  to  be  published.  Second,  and 
perhaps  more  importantly,  the  thesis  constructed  around  the 
storyboard  as  a  core  serves  as  the  essential  statement  of 
requirements.  This  statement  of  requirements  identifies 
USCENTCOM’s  needs  in  terms  of  a  decision  aid  which  will 
help  determine  the  appropriate  size  and  type  of  military 
force  required.  However,  the  determination  of  this 
military  force  size  is  only  the  kernel,  or  initial  phase, 
of  this  DSS.  There  is  room  for  considerable  expansion  of 
the  DSS  particularly  with  the  incorporation  of  some  models 
which  will  be  discussed  later.  Obviously,  no  design  using 
the  adaptive  design  process  is  ever  totally  complete,  but 
refinements  to  the  design  as  well  as  the  DSS  itself  are 
continuously  being  made.  The  potential  contribution  of  the 
NEO  DSS  is  significant,  not  only  in  reducing  the  amount  of 
planning  time  needed  but  also  in  the  determination  of  a 
military  force  size  which  is  supportable  and  verifiable  to 
some  extent  (i.e.  via  SOTACA).  In  addition  to  the  frequent 
personnel  changes  within  any  military  organization  and  the 
corresponding  lag  time  in  experience  and  learning  the  job, 
the  crisis  situation  of  a  NEO  often  demands  the  creation  of 
ad  hoc  planning  teams  versus  planning  teams  already  in 
place.  These  ad  hoc  planning  teams  may  have  little 
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experience  with  a  NEO  scenario.  Consequently,  the  worth 
factor  of  having  a  NEO  DSS,  which  provides  a  framework  of 
what  factors  should  be  considered  in  the  planner’s  decision 
process,  cannot  be  underestimated. 

Based  on  the  above  discussion,  the  author  strongly 
recommends  that  the  design  of  the  kernel  DSS  be  implemented 
as  soon  as  possible. 

Model  Base  Incorporation 

There  are  several  places  where  models  can  be 
incorporated  into  the  NEO  DSS  model  base.  These 
enhancements  to  the  model  base  will  not  require  any  models 
or  simulations  to  be  built  from  scratch  since  those 
identified  within  this  thesis  have  already  been  developed. 

The  first,  and  perhaps  most  significant,  of  these 
models  is  the  State  of  the  Art  Contingency  Analysis 
( SOTACA )  model.  SOTACA  is  one  of  two  models  developed  for 
JCS  under  the  auspices  of  the  Modern  Aids  to  Planning 
Program  ( MAPP ) .  SOTACA  provides  a  means  to  evaluate 
alternative  courses  of  action  which  wargames  each 
alternative.  SOTACA  was  designed  for  small  scale  force-on- 
force  analysis  and  this  is  ideally  suited  for  incorpoation 
in  the  NEO  process.  In  this  application,  SOTACA  can  be 
used  to  verify  the  size  and  type  of  military  force 
structure  identified  earlier  in  the  DSS.  Based  on  the 


network  established  and  the  given  threat,  a  determination 


can  be  made  as  to  the  adequacy  of  the  size  and  type  of  the 
military  security  force.  Presently,  USCENTCOM  NEO  planners 
use  a  software  program  called  CONSCREEN  to  evaluate  NEO 


alternative  courses  of  action.  This  program  appears  to  be 
somewhat  biased  because  the  values  incorporated  into 
CONSCREEN  are  input  by  the  same  individual  or  group  which 
developed  the  alternative  courses  of  action.  SOTACA ,  which 
is  a  completely  separate  model  although  still 
deterministic,  would  offer  more  objectivity  in  determining 
force  size  and  type  and  therefore  a  better  course  of 
action . 

Another  specific  application  for  SOTACA  would  be  in 
the  determination  of  an  optimal  route  of  evacuation  from 
each  noncombatant  location  to  the  specific  evacuation  site 
(airfield/port).  SOTACA  is  capable  of  determining  the 
shortest  route  or  the  route  which  takes  the  least  amount  of 
time.  The  least  amount  of  time  route  would  take  into 
account  any  anticipated  conflict  with  the  enemy  along  that 
route.  More  information  relative  to  the  specific 
application  of  SOTACA  in  the  NEO  DSS  model  base  can  be 
found  in  Appendix  B. 

Once  the  size  and  type  of  the  military  force  has  been 
determined,  the  next  step  in  the  process  would  be  to 
determine  the  specific  logistics  and  support  requirements. 
Several  models  are  available,  one  of  which  is  the  Logistics 


type  unit,  mission,  and  distance  involved,  a  logistics 
support  package  is  determined  and  provided  to  the  user. 

After  the  support  package  has  been  determined  along 
with  the  total  number  of  personnel  in  the  military  security 
force  and  the  number  of  noncombatants,  some  type  of  model 
is  needed  to  determine  the  specific  airlift/sealift 
requirements.  A  model  called  RAPIDSIM  developed  by  J4,  JCS 
is  available  which  which  not  only  determines 
a i r 1 i f t /seal i f t  requirements  but  also  their  availability. 

It  is  not  known  how  responsive  or  time  sensitive  RAPIDSIM 
is  since  it  was  initially  designed  to  support  deliberate 
planning  and  not  crisis  action  or  contingency  planning 
(MAPP  Conference,  1987).  Another  model  which  could  be  used 
to  determine  aircraft  availability  is  the  Military  Airlift 
Command’s  (MAC)  Global  DSS .  This  DSS  is  intended  to 
provide  instantaneous  feedback  to  the  user  on  the  present 
status  of  all  aircraft  belonging  to  MAC.  This  data  should 
be  accessed  via  CENTCOM’s  Command  and  Control  Information 
System  ( CCIS ) . 

Interfaces  between  the  NEO  DSS  and  the  models  or 
support  systems  discussed  above  would  be  necessary  to 
develop  a  totally  supportable  NEO  plan. 
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in  terms  of  flexibility,  identification  of  user  needs,  and 
responsiveness  to  user's  changing  requirements  and  desires. 
A  direct  consequence  of  using  the  adaptive  design  process 
was  the  ability  to  narrow  the  problem  space  and  focus  on 
one  key  area,  or  kernel,  on  which  to  expand.  This  kernel 
for  the  NEO  DSS  design  was  the  determination  of  the 
military  force  size  and  type  needed  to  insure  the  safe 
evacuation  of  the  noncombatants.  The  tools  (i.e.  concept 
mapping,  storyboarding)  used  in  the  adaptive  design  process 
proved  to  be  extremely  valuable  and  provided  the  impetus  to 
this  thesis  effort. 

The  first  tool  used  in  support  of  the  adaptive  design 
methodology  was  the  idea  of  concept  mapping.  Concept 
mapping  as  discussed  in  Chapter  Two  and  applied  in  Chapter 
Three  was  instrumental  in  capturing  the  problem  space  and 
identifying  user’s  needs  and  requirements.  The  concept  map 
represented  a  point  of  departure  for  the  remainder  of  the 
thesis  effort.  Concept  mapping  allowed  the  user  to  see 
exactly  how  his  thoughts  and  explanations  were  being 
perceived  by  the  interviewer/designer  in  pictorial  format. 
If  something  on  the  concept  map  was  in  error  as  a  result  of 
misinterpretation,  feedback  from  the  user  was  instantaneous 
and  changes  to  the  concept  map  were  immediately  made. 

The  follow-on  step  to  concept  mapping  waB  the 
storyboarding  technique  also  discussed  previously  in 
detail.  Another  extremely  valuable  tool,  storyboarding 


allowed  the  designer  to  expand  on  the  ideas  presented  in 
the  concept  map.  The  storyboarding  process  also  proved 
excellent  at  capturing  further  user  requirements  and 
focusing  on  the  "kernel"  which  will  serve  as  the  nucleus  on 
which  to  expand  the  DSS .  The  ability  of  the  user  to 
provide  the  designer  with  immediate  feedback  in  regard  to 
the  screen  displays  within  the  storyboard  corrected  any 
further  misperception  and  provided  future  direction. 
Interest  about  the  DSS  was  generated  and  maintained  because 
something  was  being  designed  based  strictly  on  user  stated 


needs  and  requirements  and  not  what  the  designer  thought 
the  user  wanted.  Also,  the  user  perceived  the  designer  as 
being  very  responsive  to  his  needs. 

Another  direct  result  of  the  storyboarding  process  was 
that  some  of  the  information  requirements  which  were 
identified  as  critical  information  needs  on  the  screen 
displays  triggered  the  USCENTCOM  staff,  especially  J2  and 
J5,  to  satisfy  "priority  intelligence  requirements".  Since 
these  requirements  have  now  been  identified,  the  staff  can 
begin  satisfying  these  requirements  rather  then  waiting  for 


the  NEO  situation  to  start.  Even  if  the  USCENTCOM  staff 
cannot  satisfy  the  requirements  now,  they  can  prepare  the 
collection  requirements  for  immediate  tasking  if  the  NEO 


situation  occurs. 

One  of  the  requirements  of  using  the  adaptive  design 


approach  is  that  there  needs  to  be  frequent  face-to-face 


r  »'•  aT”  *>  u“ *  m'"  *«*V  -  *-  *'m  •'*  »  *  /*  ^  *  *  •  *  »  V ,*  '  *  -  "  *  X 
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meetings  between  the  user  and  the  designer/builder.  This 
requirement  becomes  a  disadvantage  if  the  user  is  at  a 
distant  location  and  the  designer/builder  is  constrained  by 
funding  constraints  along  with  academic  responsibilities 
which  in  turn  limit  the  amount  of  visits  which  can  be 
conducted.  Although  there  were  only  two  meetings  between 
the  USCENTCOM  user  and  designer,  the  adaptive  design 
methodology  still  demonstrated  a  viable  and  beneficial 
approach  in  insuring  a  common  understanding  of  the  problem 
and  the  inherent  requirements  between  the  user  and  builder. 
The  traditional  approach  of  systems  design  is  simply 
inadequate  and  not  responsive  to  user  needs  and 
requirements  particularly  when  there  is  a  great  deal  of 
subjectivity  involved  in  the  decision  process. 

Recommendations 

This  research  resulted  in  the  identification  of  three 
specific  recommendations.  First  and  foremost,  USCENTCOM  in 
conjunction  with  the  Air  Force  Institute  of  Technology 
(AFIT)  should  pursue  a  course  of  action  which  would  allow 
development  of  the  kernel  DSS  designed  as  a  result  of  this 
thesis.  The  storyboard  with  the  attendent  screen  displays 
serve  as  a  statement  of  requirements  and  provide  a  logical 
starting  point  for  the  relational  data  base  development 
process.  As  a  thesis  effort,  AFIT  students  have  the 
capability  to  deliver  a  working  ’’kernel"  system  on  which  to 
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expand.  The  cost  for  USCENTCOM  is  minimal  in  terms  of  TDY 
funds  for  students  to  visit  USCENTCOM. 

Second,  the  data  base  required  to  support  this  NEO 
Decision  Support  System  will  of  necessity  be  quite  large. 
Hopefully,  the  DSS  could  use  the  already  existing  CCIS  data 
base.  Considering  the  fact  that  there  are  seventeen 
countries  in  USCENTCOM’s  area  of  responsibility,  uploading 
the  data  base  will  take  considerable  time  and  effort. 
However,  in  keeping  with  the  adaptive  design  premise  of 
starting  small  and  expanding,  USCENTCOM  should  focus  its 
initial  efforts  on  one  country  (e.g.  Sudan).  Additionally, 
to  support  the  data  base  with  current  information,  all 
USCENTCOM  major  staff  sections  will  require  access  to  the 
data  base  to  provide  information  updates  needed  to  support 
the  decision  process  in  the  event  of  a  NEO.  Consequently, 
recommend  that  a  Local  Area  Network  (LAN)  be  established 
between  the  staff  sections  and  the  NEO  DSS  data  base. 

Finally,  USCENTCOM  should  initiate  a  program  to  design 
their  own  decision  support  systems  or  aids  using  the 
adaptive  design  methodology.  Recognizing  the  fact  that 
there  is  usually  not  enough  time  or  resources  available  to 
proceed  on  any  large  scale,  the  focus  should  be  on 
something  small  which  is  needed.  In  this  time  of  shrinking 
military  budgets,  money  will  become  more  scarce. 
Consequently,  the  availability  of  contractors  should  be 
used  to  build  systems.  A  considerable  amount  of  contractor 


time  is  spent  performing  front-end  analysis,  feasi  bility 
studies,  and  determining  requirements.  From  a  user’s 
perspective,  this  time  is  wasted.  The  use  of  a  storyboard 
allows  the  user  rather  than  the  contractor  to  state 
requirements.  Using  the  adaptive  design  approach,  the  user 
will  be  better  able  to  state  and  manage  his  requirements. 
Based  on  user  familiarity  with  his  job,  the  user  is  in  the 
best  position  to  design  what  he  really  needs.  Keeping  this 
premise  in  mind,  the  dollars  can  be  better  spent  by  having 
the  contractor  concentrate  on  building  the  DSS  using  the 
user  generated  requirements.  The  author  recommends  this 
approach  be  considered  in  the  future  design  and  building  of 
Decision  Support  Systems. 


APPBNDIX  A  STORYBOARD 


This  appendix  contains  the  storyboard  with  the 
respective  screen  displays  for  the  kernel  system  (i.e. 
military  force  size  and  type  determination)  described  in 
Chapter  Three.  The  storyboard  was  designed  and  constructed 
on  the  Apple  II  computer  using  Macintosh  software  (i.e. 
MacDraw ) . 
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APPENDIX  B  SOTACA 

This  appendix  contains  a  description  of  the  State  of 
the  Art  contingency  Analysis  (SOTACA)  model  and  how  it  may 
be  applied  as  an  evaluation  mechanism  in  assessing  various 
courses  of  action  in  a  Noncombatant  Evacuation  Operations 
plan.  More  specifically,  SOTACA  can  be  used  to  verify  the 
size  and  type  of  the  military  force  previously  determined 
by  the  NEO  planner.  The  sources  of  information  for  this 
appendix  are  the  "SOTACA  User’s  Manual"  dated  April  1987 
and  "A  SOTACA-Based  Methodology  Assessing  the  Impact  of 
Mobility  Enhancements  on  Civil-Military  Operations",  a 
study  prepared  by  the  U.S.  Pacific  Command,  dated  6  January 
1988. 
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One  of  the  principal  conclusions  drawn  from  Chapter 
Four  of  this  thesis  was  the  recognition  and  need  for  some 
type  of  course  of  action  assessment  system.  The  decision 


as  to  which  size  and  type  of  military  force  needed  to 
insure  the  security  of  the  noncombatants  was  one  that  was 
very  subjective  on  the  part  of  the  Noncombatant  Evacuation 
Operations  (NEO)  planner  and  dependent  on  time,  distance, 
and  threat  factors.  It  was  quite  evident  that  some  type  of 
wargaming  model  was  needed  which  could  simulate  the 
particular  host  country  environment  to  include  the  threat 
and  provide  some  type  of  feedback  to  the  planner  relative 
to  the  size  and  type  of  military  force  selected  to  perform 
the  NEO  mission.  Additionally,  the  simulation  had  to  be 
responsive  to  the  planner  since  time  was  such  a  critical 
factor.  As  a  result  of  this  conclusion,  a  recommendation 
was  made  to  incorporate  the  State  of  the  Art  Contingency 
Analysis  (SOTACA)  model  into  the  Decision  Support  System 
(DSS)  which  supported  NEO  planning. 

SOTACA  is  a  computer  based,  analytical  model  designed 
to  support  crisis  action  planning.  Developed  under  the  JCS 
sponsored  Modern  Aids  to  Planning  Program  (MAPP),  SOTACA 
will  eventually  support  a  future  phase  of  the  Joint 
Operational  Planning  and  Execution  System  (JOPES).  SOTACA 
was  specifically  designed  to  support  planning  at  the 
joint/unified  command  level  by  providing  a  means  for  rapid 
evaluation  of  alternative  courses  of  action  (SOTACA  User's 
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Manual,  1987:  iii). 


SOTACA  addresses  the  firepower, 
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maneuver,  and  time  and  space  considerations  addressed  by 
other  models.  Unlike  other  models,  however,  SOTACA  aims 
for  a  realistic  representation  of  the  multidimensional 
conflict  usually  found  in  Third  World  contingency 
situations.  These  situations  typically  involve  a  more 
varied  mix  of  force  components  than  other  contingency 
situations  and  require  a  greater  consideration  of 
political,  economic,  social,  and  psychological  factors" 
(SOTACA  Handbook,  1987:  1-3).  Because  of  SOTACA’ s 
flexibility  in  its  approach  to  power  and  vulnerability 
values,  it  appears  to  be  an  excellent  model  to  assess  NEO 
alternative  courses  of  action,  in  this  case,  the  NEO 
planner’s  subjective  determination  of  the  size  and  type  of 
the  military  security  force. 
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1.  SOTACA  Definition  of  Terms.  Prior  to  a 
discussion  of  how  SOTACA  can  be  uBed  to  evaluate  NEO 
alternative  courses  of  action,  it  will  be  necessary  to 
explain  some  terms,  common  to  the  running  of  SOTACA, 
particularly  as  they  apply  to  the  NEO  environment. 

a.  BLUE  Forces:  Friendly  forces,  those  U.S. 
forces  identified  to  insure  the  security  of  U.S. 
noncombatants  during  the  evacuation  process. 

b.  RED  Forces:  Enemy  forces,  those  forces 
opposed  to  the  safe  evacuation  of  U.S.  noncombatants.  These 


■r, 

jf: 


»  « 


B-3 


$ 


forces  may  include  national  military  forces,  paramilitary 
forces,  local  government  forces,  local  and  national  police, 


K 
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and  the  civil  populace. 

c.  Task  Force:  A  subset  of  the  total  force 
assigned  to  accomplish  a  specific  task.  In  the  NEO 
environment,  the  friendly  force  is  no  smaller  than  platoon 
size  and  will  be  used  for  airfield/port  security,  site 
security  at  each  noncombatant  location,  and  route  security 
between  the  noncombatant  location  to  the  evacuation  site 
airfield  or  port. 

d.  Confrontation:  The  engagement  of  opposing 
task  forces.  In  SOTACA,  confrontation  can  only  take  place 
at  nodes  *  ' thin  the  network  and  not  along  routes  or  links. 
This  will  be  discussed  in  more  detail  later. 

e.  Power:  The  attribute  of  one  force  that 
influences  the  opposing  force.  For  the  NEO  environment, 
there  are  two  types  of  power  which  can  be  represented. 

These  two  types  of  power  are  military  and  political  power. 
"Military  power  acts  on  the  military  and  paramilitary  units 
of  the  opposing  force.  Political  power  acts  on  the  civil 
populace.  Two  types  of  political  power  are  represented: 
influence  and  coercion.  Influence  is  the  political  power 
which  causes  a  segment  of  the  populace  to  shift  allegiance 
from  the  opposing  force  to  the  unit  projecting  influence. 
Converse 'y,  coercion  is  the  political  power  that  pushes  a 
population  segment  favoring  the  friendly  force  into  the 
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opposition  camp"  (McCurdy,  1988:  1-2).  The  need  to 
represent  coercion  as  a  political  power  in  the  NEO 
environment  is  readily  apparent.  A  segment  of  the 
population  which  may  be  on  the  fringe  of  supporting  the 
force  which  threatens  the  security  of  U.S.  noncombatants 
may  be  pushed  over  to  the  enemy  side  if  they  perceive  a 
threat  to  their  territory,  particularly  with  the  insertion 
of  U.S.  combat  forces. 

f.  Confronter :  Confronters  contribute  power  to 
a  force  and  are  vulnerable  to  the  power  of  an  opposing 
force.  In  the  NEO  case,  the  friendly  force  has  both 
military  and  political  power  since  it  can  affect  both  the 
opposing  military  force  and  the  civil  populace.  However, 
the  RED  force  (i.e.  enemy  force)  has  only  military  power 
because  the  friendly  force  is  only  vulnerable  to  military 
power . 

g.  Relative  Vulnerability:  The  relative 
vulnerability  of  a  specific  confronter  or  force,  engaged  in 
a  given  mission,  to  each  category  of  power  projected  by  the 
opposition.  In  the  NEO  environment,  the  BLUE  or  friendly 
force  is  vulnerable  to  the  RED  forces  military  power.  On 
the  other  hand,  the  RED  force  is  vulnerable  to  both  the 
military  and  political  power  exerted  by  the  BLUE  force. 

h.  Network:  The  representation  of  an  area  of 
operations  using  critical  locations  (nodes)  and  the  lines 
of  communication  (links)  between  these  nodes.  For  the  NEO 
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environment,  the  nodes  are  at  each  noncombatant  location, 


evacuation  site  (i.e.  airfield/port),  and  the  specific 


location  along  each  evacuation  route  where  confrontation 


may  be  expected.  The  links  are  merely  the  road  network 


between  the  noncombatant  location  to  the  particular 


evacuation  site  (i.e.  airfield/port)  ( SOTACA  User’s  Manual, 


1987 :  1-1  to  1-3  )  . 


The  remainder  of  the  terms  which  are  specific  to  the 


operation  and  running  of  the  SOTACA  model  can  be  found  in 


the  SOTACA  User’s  Manual. 


2.  SOTACA  Model  Characteristics 


a.  SOTACA  is  a  fast-running,  interactive  model 


used  to  assess  the  results  of  a  confrontation  between  two 


opposing  forces.  SOTACA  is  capable  of  representing  six  to 


eight  hours  of  conflict  in  about  30  seconds. 


b.  SOTACA  is  a  network-based  model  as  discussed 


earlier.  The  user  defines  hiB  area  of  operations  using 


nodes  and  links.  SOTACA  can  provide  a  variety  of  link 


types  and  conditions  which  in  turn  allow  the  user  to 


control  the  speeds  at  which  forces  can  move  between  nodes- 


c.  The  SOTACA  user  also  defines  the  friendly 


and  enemy  forces  used  in  the  simulation.  In  the  NEO 


environment,  the  friendly  force  is  going  to  be  a  military 


police  unit  or  some  type  of  combat  force,  typically  an 


infantry  unit  (e.g.  Army,  Marines).  The  enemy  force  could 
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be  paramilitary  forces  as  well  as  national  military  forces, 
local  government,  and  local  and  national  police. 
Additionally,  propaganda  units  and  the  civil  populace  must 
also  be  considered.  The  type  of  enemy  force  to  be 
portrayed  in  SOTACA  will  be  the  result  of  the  latest 
intelligence  estimates  and  threat  situation  which  is  the 
responsibility  of  USCENTCOM  J2. 

d.  The  SOTACA  user  also  defines  the  unit’s 
route  through  the  network.  In  the  NEO  environment,  this 
route  is  from  each  of  the  noncombatant  locations  to  the 
evacuation  site  (i.e.  airfield/port).  In  planning  the  NEO, 
planners  want  to  avoid  any  conflict  or  confrontation  along 
the  route  if  at  all  possible.  The  reason  is  obvious;  the 
purpose  of  the  military  force  is  to  insure  the  security  of 
the  noncombatants  and  the  best  method  of  doing  this  is  to 
avoid  any  confrontation  if  possible. 


3.  The  Noncombatant  Evacuation  Operation  (NEO) 
Scenario.  For  the  purpose  and  scope  of  this  thesis  effort, 
the  country  of  Sudan  was  chosen  as  the  host  country.  The 
political  situation  has  deteriorated  in  Sudan  to  the  point 
where  the  Sudanese  government  can  no  longer  insure  the 
security  of  U.S.  nationals  in  country,  specifically 
Khartoum.  Because  of  this  situation,  the  U.S.  Ambassador 
at  Khartoum  has  exercised  his  right  to  request  military 
support  in  the  conduct  of  a  NEO.  One  airfield  has  been 
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chosen  as  the  evacuation  site  and  must  be  secured.  Further 


complicating  the  NEO  is  the  fact  that  the  U.S. 
noncombatants  are  located  at  three  different  locations 
throughout  Khartoum.  Security  must  be  provided  at  each 
noncombatant  location  as  well  as  along  each  route  between 
the  noncombatant  location  to  the  airfield  evacuation  site. 
Intelligence  reports  indicate  that  there  may  be  some 
paramilitary  forces  threatening  the  security  of  U.S. 
nationals  in  Khartoum.  Additionally,  the  civil  populace  in 
Khartoum  is  becoming  more  anti-American  each  day  due  to 
recent  American  actions  in  the  Persian  Gulf. 

4.  Measure  of  Effectiveness.  A  measure  of 
effectiveness  ( MOE )  used  in  the  development  of  the  NEO  plan 
is  to  determine  the  minimum  military  force  needed  to  insure 
the  security  of  U.S.  noncombatants  from  their  respective 
noncombatant  locations  in  Khartoum  to  the  evacuation 
airfield  site  and  subsequent  evacuation  to  Cairo-West.  The 
military  force  size  and  type  must  be  kept  to  a  minimum,  not 
only  from  an  airlift/sealift  perspective,  but  a  political 
perspective  as  well.  A  smaller,  military  police  force 
would  have  less  coercion  power  than  a  larger,  combative 
infantry  force.  The  political  sensitivities  of  what  type 
of  force  to  employ  in  order  to  avoid  an  escalation  of  the 
particular  threat  environment  iB  an  important  factor  in  the 
NEO  planning  process. 
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5.  Mission  Modes,  Categories  of  Power,  and 
Confronters . 

a.  Mission  modes  as  defined  in  the  SOTACA 
User's  Guide  are  "a  classification  of  battle  intensities  or 
methods  of  conflict  (e.g.  attack,  defend,  delay,  hold). 

Each  task  force  is  assigned  a  primary  mission  mode  that 
directs  its  level  of  aggression  when  confronted"  (SOTACA 
User’s  Guide,  1987:  1-2).  Based  on  any  given  situation, 
the  BLUE  or  friendly  force  may  have  to  attack,  defend,  or 
presume  a  mission  mode  of  "control"  referred  to  in  the 
USPACOM  study.  The  term  "control"  corresponds  to 
controling  the  hearts  and  minds  of  the  people  (McGurdy, 
1988:  6).  Since  the  friendly  forces  are  only  vulnerable  to 
military  power,  because  of  their  makeup  as  well  as  the 
limited  amount  of  time  spent  in  the  host  country,  the 
opposing  enemy  force  does  not  have  a  "control"  mission 
mode,  only  attack  or  defend. 

b.  As  discussed  earlier,  categories  of  power 
represent  both  military  and  political  power  projected  by 
friendly  U.S.  forces  and  only  military  power  is  projected 
by  enemy  forces.  "Political  power  is  further  divided  into 
influence  and  coercion  which  represent  positive  and 
negative  political  power,  respectively"  (McGurdy,  1988:  6). 
A  more  detailed  definition  of  the  types  of  power  involved 
in  this  NEO  environment  was  addressed  earlier  in  the 
definition  of  terms  portion  of  this  appendix.  Since 
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friendly  U.S.  forces  are  not  vulnerable  to  any  type  of 
political  power  then  the  enemy  forces  are  unable  to  project 
this  type  of  power.  However,  U.S.  forces  are  able  to 
project  both  types  of  power  because  the  enemy  forces  are 
vulnerable  to  both  military  and  political  power.  It  should 
be  kept  in  mind  that  friendly  coercion  is  really  a  positive 
factor  for  the  enemy  and  not  a  negative  one. 

c.  The  confronters  selected  for  the  NEO 
application  can  be  any  size  and  type  unit.  For  friendly 
forces,  this  is  platoon  size  or  greater  and  either  military 
police  or  infantry.  For  enemy  forces,  confronters  can  be 
national  military  forces,  paramilitary  forces,  local 
government,  local  and  national  police,  and  the  civil 
populace.  All  confronter  forces  within  the  NEO  environment 
project  some  degree  of  power  except  for  the  civil  populace. 
The  populace  confronter  is  calibrated  so  that  it  projects 
no  power,  however,  it  is  vulnerable  to  the  political  power 
projected  by  the  friendly  forces. 


6.  Model  Calibration. 

\S  a.  SOTACA  model  calibration  consists  of  power, 

„  vulnerability,  attrition,  and  forward-line-of-troops  (FLOT) 

movement  calibration.  For  the  NEO  environment,  FLOT 
movement  tracking  is  not  necessary  and  therefore  would  not 
be  calibrated  (i.e.  there  is  no  FLOT). 

b.  Power  calibrations  for  use  in  the  NEO 

i 
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environment  may  be  based  on  Saaty’a  pairwise  comparison 
technique,  which  is  used  to  calculate  the  power  and 
vulnerability  values  for  all  confronters  in  the  scenario. 
USPACOM  did  not  base  their  power  calibrations  on  the 
pairwise  comparison  technique  in  its  study,  but  rather 
professional  and  personal  experience  (McGurdy,  1988:  12). 

In  this  case,  the  BLUE  military  force  projects  military  and 
political  power.  The  RED  military  force  projects  only 
military  power.  The  civil  populace  does  not  project  either 
military  or  political  power. 

c.  Vulnerability  calibrations  follow  the  same 
type  of  procedure  as  established  in  the  power  calibrations. 
The  BLUE  military  force  is  only  vulnerable  to  military 
power,  whereas  the  RED  military  force  is  vulnerable  to  both 
military  and  political  power. 

d.  Based  on  historical  data  (i.e.  Dominican 
Republic,  Grenada,  etc.),  attrition  calibrations  would  have 
to  be  determined  and  input  into  SOTACA. 

7.  Unit  Movements.  The  design  of  this  application 
requires  that  each  BLUE  or  U.S.  military  force  unit  be 
represented  by  two  SOTACA  forces,  one  representing  its 
military  and  influence  power  and  the  other  representing  its 
coercive  power.  "To  assure  that  all  of  a  unit’s  power  is 
accounted  for  in  assessing  confrontation  outcomes,  the  blue 
and  red  forces  have  to  be  maneuvered  simultaneously  over 
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the  same  route"  (McGurdy,  1988:  25). 

8.  Summary.  The  main  purpose  of  SOTACA  is  to 
provide  commanders  and  staff  planners  with  an  automated 
tool  which  they  can  use  to  rapidly  analyze  and  assess 
alternative  courses  of  action  for  small-scale  operations. 
Taken  in  the  context  of  the  NEO  situation  and  mission,  the 
responsible  commander  wants  to  know: 

a.  What  forces  are  available? 

b.  What  is  the  best  force  mix  that  can  be  built 
keeping  in  mind  that  the  force  mix  needs  to  be  kept  to  the 
minimum  to  accomplish  the  mission? 

c.  What  is  the  best  organization  and 
deployment/employment  plan  for  that  force  mix? 

(SOTACA  User’s  Guide,  1987:  2-2) 

SOTACA  attempts  to  answer  these  questions  and  provide  the 
commander  or  planner  some  type  of  feedback  to  continue  the 
planning  effort  in  the  minimum  amount  of  time. 

The  scope  of  this  thesis  effort  focuses  on  the 
determination  of  the  size  and  type  of  the  military  force 
needed  to  insure  the  security  of  U.S.  noncombatants  from 
Sudan.  Given  the  ideal  NEO  environment  which  favors  the 
use  of  a  network  based  simulation  system,  SOTACA  can  be 
used  as  a  method  of  verification  for  the  NEO  planners  in 
determining  the  appropriate  military  force  size  and  type. 

Based  on  the  USPACOM  study,  the  material 
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presented  in  this  appendix  provides  an  approach  and 
possible  starting  point  for  SOTACA  application  in  a  NEO 
scenario . 


APPENDIX  C  HOOKBOOK 


This  appendix  provides  further  suggestions  and 
recommendations  for  enhancing  the  Noncombatant  Evacuation 
Operation  (NEO)  Decision  Support  System  (DSS)  and  the  use 
of  the  adaptive  design  methodology.  The  hookbook  items  are 
a  result  of  various  thoughts  and  ideas  which  occured 
throughout  the  duration  of  this  thesis  effort.  These 
hookbook  items  are  broken  down  into  two  categories  (i.e. 

DSS  and  Adaptive  Design  Enhancements)  and  arranged 
chronologically  within  category. 
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Eventually,  an  expert  system  should 


be  developed  which  can  provide  the  user  some 
recommendations  on  what  size  and  type  of  military  force  is 
needed  for  the  security  mission  based  on  the  threat,  time, 
and  distance  factors.  The  decision  rules  for  thiB  expert 
system  would  have  to  be  based  on  some  type  of  historical 
data  from  previous  NEO  (e.g.  Dominican  Republic,  Grenada). 
Such  an  expert  system  could  drastically  reduce  the  amount 
of  time  needed  to  determine  the  right  size  force  mix  in 
addition  to  reducing  the  uncertainty  on  the  part  of  the 
user’s  subjective  judgement. 


18  Aug  1987 


Consideration  should  be  given  to  the 


idea  of  triggering  some  type  of  window  to  open  up  on  the 
screen  display  which  would  provide  a  map  layout  depicting 
the  closest  staging  base  for  aircraft  near  the  particular 
country  of  NEO  interest,  in  this  case  Sudan.  Of  course, 
the  staging  base  would  have  to  be  in  a  country  which  was 
favorable  to  supporting  U.S.  operations  and  provide  limited 
basing  rights.  A  considerable  amount  of  planning  time 
would  be  saved  if  this  type  of  information  was  available 
and  could  be  provided  via  the  NEO  DSS . 


-14  Sep  1987 


The  NEO  DSS  needs  to  have  access  to 


some  type  of  map  data  base  which  is  maintained  and  updated. 
Recommend  that  the  NEO  DSS  have  access  to  the  CIA  Worldwide 
Map  Data  Base  which  is  also  currently  integrated  with 


SOTACA.  This  requirement  should  not  require  a  significant 
amount  of  time  or  effort,  and  should  be  easily  implemented. 

-6  Nov  1987  Initially,  the  focus  of  developing 

alternative  courses  of  action  was  based  on  a  worst-case 
scenario,  that  being  a  hostile  NEO  environment.  Presently, 
the  NEO  DSS  is  designed  to  develop  a  course  of  action  based 
on  the  present  threat  environment  and  the  next  higher  level 
threat  if  applicable.  For  example,  suppose  the  threat 
environment  at  noncombatant  location  1  is  semi permi ss i ve ;  a 
course  of  action  would  be  planned  for  the  semipermissi ve 
environment  as  well  as  the  next  higher  level  or 
nonpermissi ve  environment.  Recommend  that  some  type  of 
matrix  system  be  developed  which  could  be  used  to  plan  for 
all  three  types  of  environment:  semipermi ssi ve , 
nonpermissive ,  and  hostile. 

-23  Nov  1987  There  are  special  support  personnel 

requirements  needed  for  the  conduct  of  a  NEO.  Some  type  of 
reminder  for  the  NEO  planner  needs  to  be  built  into  the  NEO 
DSS  which  will  remind  him  to  think  of  such  requirements  as 
a  medical  team,  military  assistance  team,  combat  control 
team,  aviation  detachment,  etc.  Special  support  personnel 
and  equipment  requirements  would  also  need  to  be  considered 
in  the  total  airlift/sealift  which  is  available. 

-6  Jan  1988  The  State  Department's  F77  report 

which  provides  a  breakout  of  the  noncombatants  by  type  and 
numbers  is  sent  via  electrical  message  (i.e.  gensor)  from 


the  U.S.  embassy  in  that  country  to  each  of  the  respective 
unified  commands.  Presently,  this  information  iB  only 
disseminated  every  six  months.  There  needs  to  be  some  type 
of  communications  link  made  available  bo  that  the  embassies 
are  able  to  update  the  NEO  DSS  directly  and  more  often  to 
avoid  the  uncertainty  common  to  this  type  of  perishable 


information 


-6  Jan  1988 


Based  on  a  meeting  with  the  new 


USCENTCOM  J5  NEO  planner,  a  user  desire  was  expressed  which 
should  be  considered  in  any  future  enhancements  to  the  NEO 
DSS.  The  ultimate  goal  of  the  NEO  DSS  Bhould  be  to  publish 
a  final  Operations  Order  (OPORD)  along  with  the  necessary 
support  documents.  It  is  recognized  that  such  publication 
is  going  to  be  based  strictly  on  the  user’s  input  and  then 
only  after  the  approval  of  the  concept  of  operations  by  the 
Commander  in  Chief,  USCENTCOM  ( USCINCCENT ) . 


-6  Feb  1988 


Recommend  that  there  be  some  type  of 


digitized  map  capability  available  which  would  be  able  to 
graphically  illustrate  the  terrain  along  the  various  road 
routes  for  evacuation  purposes.  The  map  would  have  to  be 
of  sufficient  scale  to  provide  the  user  with  a  true 
appreciation  for  the  terrain  (e.g.  1:50,000). 

Additionally,  this  map  data  would  be  displayed  on  the 
screen  via  a  window.  Presently,  only  descriptions  of  key 
terrain  are  provided  along  each  possible  evacuation  route. 


-15  Feb  1988 


The  screen  displays  portrayed  in  the 


storyboard  in  Appendix  A  are  merely  representative. 
Recommend  that  the  screens  for  each  display  be  at  least 
twenty  inches  diagonal  to  allow  for  a  better  map  display 
and  to  avoid  the  clutter  which  is  common  with  the  separate 
windows  if  they  are  activated. 

-28  Feb  1988  Recognizing  the  need  for  SOTACA  to  be 

used  in  the  role  of  assessing  the  alternative  courses  of 
action  as  well  as  verifying  the  military  security  force 
size  and  type,  there  needs  to  be  close  interface  between 
J5,  J3,  and  the  Analysis  Division  at  USCENTCOM.  As  the 
threat  information  is  made  known  and  input  into  the  NEO 
DSS,  there  should  be  some  type  of  interface  capability 
which  also  automatically  transfers  this  data  into  SOTACA. 
The  network  depicting  the  noncombatant  locations, 
evacuation  sites,  and  perspective  evacuation  routes  should 
already  have  been  predetermined  and  input.  When  J3  or  J5 
requires  a  course  of  action  assessment,  the  SOTACA  data 
base  should  be  ready  to  execute.  SOTACA  must  be  able  to 
provide  a  timely  response  or  it  will  not  be  used. 

Adaptive  Design  Enhancements 

-6  Jan  1988  The  problem  of  evaluation  of  the  NEO 

DSS  was  discussed  with  the  USCENTCOM  users.  Based  on  user 
comments,  it  was  determined  that  the  use  of  the  hookbook  to 
make  recommendations  for  product  improvement  would  not  be 
too  distractive  to  the  user.  Each  hookbook  displayed  would 
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need  to  be  tied  with  the  respective  screen  display  which 
prompted  the  user  input.  The  hookbook  provides  a  vehicle 
for  the  evaluation  process  which  seems  to  be  cumbersome  at 
best . 

-6  Jan  1988  Based  on  USCENTCOM  user  comments,  it 

is  absolutely  critical  to  have  windows  come  up  on  the  basic 
screen  display  to  maintain  continuity  of  thought  for  the 
NEO  planner.  The  planner  needs  to  have  access  to  as  many 
windows  as  possible  while  still  portraying  the  basic  screen 
display . 

-23  Feb  1988  There  is  a  definite  need  to  have  more 

frequent  meetings  between  the  USCENTCOM  user  and  the 
DSS/Data  Base  builder  to  insure  construction  of  DSS  iB  on 
track,  meets  user  requirements,  and  can  be  modified  if 
there  are  changes  in  those  requirements.  Recommend  there 
be  a  minimum  of  once-a-month  meetings  between  builder  and 
user  . 


I 


C-6 


ilL  aft*  ift/afCWC 


/. 


Alavi,  Maryam  and  Albert  H.  Napier.  "An  Experiment  in 
Applying  the  Adaptive  Design  Approach  to  DSS 
Development,"  Information  and  Management:  21-28 
(July  1984). 

Andriole,  Stephen  J.  and  others.  "Storyboarding  for  C2 

Systems  Design:  A  Combat  Support  System  Case  Study," 
Draft  Paper  (reference  LtCol  John  R.  Valusek, 
Operational  Sciences  Department,  Air  Force  Institute 
of  Technology  (AU),  Wright-Patterson  AFB  OH)  1987. 

Armed  Forces  Staff  College.  Joint  Staff  Officer’s  Guide 
1986.  AFSC  Pub  1.  Norfolk  VA:  National  Defense 
University,  1  July  1986. 

Burleson,  Donald  and  others.  "Design  and  Implementation  of 
a  Decision  Support  System  for  Academic  Scheduling," 
Information  and  Management,:  57-64  (November  1986). 

Freeman,  Cdr  Dale.  Conversation.  J-5  Plans,  United 

States  Central  Command  (USCENTCOM),  MacDill  AFB,  FL, 

30  June  1987. 

Gowin,  D.  Bob  and  Joseph  D.  Novak.  Learning  How  to  Learn. 
New  York  NY:  Cambridge  University  Press,  1984. 

Hagwood,  John.  Formal  "Systems  Languages"  in  Decision 
Support  Systems  for  Military  Commanders.  Contract 
DA JA  45-84-M-0275 .  Crook  Hall,  Sidegate  Durham  DH1 
5SZ  England,  June  1986  (AD  -A169  673). 

Joint  Chiefs  of  Staff.  "SOTACA  Handbook  for  Commanders  and 
Staff  Planners,"  Modern  Aids  to  Planning  Program,  14 
March  1986. 

Joint  Chiefs  of  Staff.  "SOTACA  Analyst’s  Guide  to  Theory," 
Modern  Aids  to  Planning  Program.  Preliminary  Draft  II, 
June  1986. 

Joint  Chiefs  of  Staff.  "SOTACA  User’s  Manual,”  Modern  Aids 
to  Planning  Program.  April  1987. 

Keen,  Peter  G.W.  "Adaptive  Design  For  Decision  Support 

Systems,"  ACM/Data  Base,  Volume  12,  Number  1,2:  15-25 
(Fall  1980). 


Keen,  Peter  G.W.  and  Michael  S.  Scott-Morton .  Decision 
Support  Systems:  An  Organizational  Perspective. 
Reading  Massachusetts:  Addison-Wesley  Publishing  Co., 
1978  . 


Kopf,  Cpt  Thomas  J.  Design  of  an  Aircrew  Scheduling 


Decision  Aid  for  the  6916th  Electronic  Security 
Squadron .  MS  Thesis  85-87.  School  of  Engineering, 
Wright-Patterson  AFB,  OH,  June  1987. 

McCurdy,  Michael  L.  A  SOTACA-Based  Methodology  for 

Assessing  the  Impact  of  Mobility  Enhancements  on 
Civil-Military  Operations.  6  January  1988. 

McFarren,  Capt  Michael  R.  Using  Concept  Mapping  to  Define 
Problems  and  Identify  Key  Kernels  During  the 
Development  of  a  Decision  Support  System.  MS  Thesis 
AFIT/GST/ENS/87M- 12 .  School  of  Engineering,  Air  Force 
Institute  of  Technology  (AU),  Wright-Patterson  AFB  OH, 
June  1 9  8 \  . 

Modern  Aids  to  Planning  (MAPP)  Conference.  Discussion  of 
Logistics  Support  Models.  J4,  Joint  Chiefs  of  Staff. 
Scott  AFB,  IL,  October  1987. 

Meador,  Lawrence  C.  and  William  L.  Rosenfeld.  "Decision 

Support  Planning  and  Analysis:  The  Problem  of  Getting 
Large  DSS  Started,"  MIS  Quarterly . :  159-175  (June 
1986). 

Rouse,  William  B.,  and  Sandra  H.  Rouse.  A  Framework  for 
Research  on  Adaptive  Decision  Aids,  1  November  1982- 
31  October  1983.  Contract  F336 1 5-82-C-0509 . 
Wright-Patterson  AFB,  OH:  Search  Technology  Inc., 
October  1983  ( AD-A1 3833 1 ) . 

Seagle,  John  P.  and  Salvatore  Belardo.  "The  Feature  Chart: 
A  Tool  for  Communicating  the  Analysis  for  a  Decision 
Support  System,"  North  Holland  Information  and 
Management,  10:  11-19  (1986). 

Sprague,  Ralph  H.  Jr.,  and  Eric  D.  Carlson.  Building 

Effective  Decision  Support  Systems.  Englewood  Cliffs 
NJ:  Prentice-Hall  Inc.,  1982. 

Sullivan,  Cdr  John  F.  "The  Dominican  Republic  Crisis--The 
Background,  The  Initial  Military  Operation,  and  The 
Controversy."  U.S.  Army  War  College,  Carlisle 
Barracks  PA,  8  April  1966. 

Valusek,  LtCol  John  R,  Class  Notes  taken  in  OPER  699, 

Decision  Support  Systems . School  of  Engineering,  Air 
Force  Institute  of  Technology  (AU),  Wright-Patterson 
AFB,  OH,  July-September  1987. 


Watson,  Hugh  J.  and  Marianne  M.  Hill.  "Decision  Support 
Systems  or  What  Didn’t  Happen  with  MIS," 

Interfaces  ,13:  81-88  (5  October  1983). 


*4 


r  ' , 

* 


0 

S' 

V. 

V, 


c- 

•V 


y.  m 
V. 


BIB-3 


b 


iiCf iv.'f vf r.y li  f vf  .Y  i'?  i~ f i^bY.'  V ' ,  fi  f , 


vv 


Captain  Stephen  R.  Kostek  was  born  on  11  August  1956 


in  Hadley,  Massachusetts.  He  graduated  from  Hopkins 
Academy  in  1974  and  received  a  Bachelor  of  Sciences  degree 
and  his  commission  from  the  United  States  Military  Academy 
in  June  1978.  In  Nov  1978,  he  graduated  from  the  Military 
Intelligence  Officer  Basic  Course  at  Ft  Huachuca,  AZ .  From 
Nov  1978  -  Aug  1980,  Captain  Kostek  served  as  a  Company 
Commander  and  Battalion  Operations  Officer  at  the  6th  Basic 
Training  Battalion,  Ft  Jackson,  SC.  From  Aug  1980  -  Jul 
1983,  he  served  as  Battalion  Intelligence  Officer  for  2d 
Battalion,  59th  Air  Defense  Artillery  and  then  G2 
Operations  and  Plans  Officer  for  HQ,  1st  Armored  Division, 
Ansbach,  FRG.  From  Jul  1983  -  Jan  1984,  Captain  Kostek 
attended  the  Military  Intelligence  Officer  Advance  Course 
at  Ft  Huachuca,  AZ .  From  Jan  1984  -  Jul  1986,  he  served  as 
an  Intelligence  Plans  and  Exercises  Officer,  Office  of  the 
Deputy  Chief  of  Staff,  Intelligence,  U.S.  Army  Forces 
Command,  Ft  McPherson,  GA .  In  Aug  1986,  Captain  Kostek 
entered  the  School  of  Engineering,  Air  Force  Institute  of 
Technology . 


Permanent  Address:  45  Lawrence  Plain  Road 

Hadley,  Massachusetts  01035 


i 


VITA-1 


UNCLASSIFIED 

CURlTY  CLASSIFICATION 


la  REPORT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 

2 a  SECURITY  CLASSIFICATION  AUThORiTY 


2b  DECLASSIFICATION /DOWNGRADING  SCHEDULE 


4  PERFORMING  ORGANIZATION  REPORT  NUMBER(S) 

AF I T/G  S  T/ENS/8 8M~ 7 


6a.  NAME  OF  PERFORMING  ORGANIZATION 

School  of  Enqineering 


6c  ADDRESS  (City,  State,  and  ZIP  Code) 


REPORT  DOCUMENTATION  PAGE 

iON  lib  RESTRICTIVE  MARKINGS 


Form  Approved 
OMB  No  0704-01 B8 


6b  OFFICE  SYMBOL 
(If  applicable) 

AFIT/ENS 


Air  Force  Institute  of  Technology 
Wright-Patterson  AFB  OH  45433-6583 


8a  NAME  OF  FUNDING  /  SPONSORING 
ORGANIZATION 


80  OFFICE  SYMBOL 
(If  applicable) 


3  DISTRIBUTION /AVAILABILITY  OF  REPORT 

Approved  for  public  release; 
distribution  unlimited 


5  MONITORING  ORGANIZATION  REPORT  NUMBER(S) 


7a.  NAME  OF  MONITORING  ORGANIZATION 


7b  ADDRESS  (C/ty,  State,  end  Z/P  Code) 


9  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 


Be.  ADDRESS  (City,  State,  and  ZIP  Code) 


1 1  TITLE  (include  Security  Classification) 

See  Box  19 


12  PERSONAL  AUTHOR(S) 

Stephen  R.  Kostek,  B.S 


10  SOURCE  OF  FUNDING  NUMBERS 


R.  Kostek,  B.S,,  Capt ,  USA 


13a.  TYPE  OF  PEPORT 

MS  Thesis 


13b  TIME  COVERED 
FROM  TO 


PROJECT 

TASK 

NO 

NO 

WORK  UNIT 
ACCESSION  NO 


14.  DATE  OF  REPORT  (Year,  Month,  Day)  |15  PAGE  COUNT 

1988  March  153 


COSATI  CODES 


SUB-GROUP 


GROUP 


01 


02 


19  ABSTRACT  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 


18  SUBJECT  TERMS  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 

Noncombatant  Evacuation  Operations, 

Adaptive  Design,  Decision  Support  System 


Title:  A  USER'S  DESIGN  OF  A  DECISION  SUPPORT  SYSTEM  FOR 

NONCOMBATANT  EVACUATION  OPERATIONS  FOR  UNITED  STATES 
CENTRAL  COMMAND 

Thesis  Chairman:  John  R.  Valusek,  Lt  Col,  USAF 

Assistant  Professor  of  Operations  Research 


20  DISTRIBUTION /AVAILABILITY  OF  ABSTRACT  21  ABSTRACT  SECURITY  CLASSIFICATION 

QUNCLASSIFIED'UNUMITED  □  SAME  AS  RPT  □  OTIC  USERS  UNCLASSIFIED 


22a  NAME  OF  RESPONSIBLE  INDIVIDUAL  22b  TELEPHONE  (Include  Area  Code)  \  22 c  OFFICE  SYMBOL 

John  R.  Valusek ,  Lt  Col.  USAF  (513)  ;  ~  ~ 


DD  Form  1473,  JUN  86  Previous  editions  are  obsolete  _ SECURITY  CLASSIFICATION  Of  THIS  PAGE 

UNCLASSIFIED 


UNCLASSIFIED 


Perhaps  the  most  sensitive  and  most  likely  to  occur 
crisis  operation  within  any  of  the  geographically  oriented 
unified  commands  is  the  conduct  of  Noncombatant  Evacuation 
Operations  (NEO).  NEO  is  a  system  which  has  been  developed 
in  order  to  evacuate  all  U.S.  civilians  and  military 
dependents  from  a  given  area  in  the  event  of  an  emergency 
situation  which  poses  a  threat  to  their  safety.  The 
purpose  of  this  research  effort  is  to  develop  a  conceptual 
design  of  a  Decision  Support  System  (DSS)  which  will 
support  one  of  the  unified  commands,  United  States  Central 
Command  (USCENTCOM),  in  determining  the  appropriate 
military  force  size  and  type  to  be  used  to  support  the  NEO. 
The  most  significant  factors  which  impact  on  the  NEO  force 
size  determination  process  are  the  time  constraints 
involved  and  the  need  for  intuitive  {i.e.  subjective)  input 
versus  objective  input.  This  paper  expands  on  the 
methodology  used  to  capture  the  subjective  judgements  and 
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system.  This  methodology,  referred  to  as  the  adaptive 
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